#5705 BLOC 8.2.0 (: sudo gives "can't access tty" errors.

[Zarro Boogs per Child]

#5705: sudo gives "can't access tty" errors.
-------------------------+--------------------------------------------------
   Reporter:  cjb        |       Owner:  cscott                       
       Type:  defect     |      Status:  new                          
   Priority:  blocker    |   Milestone:  8.2.0 (was Update.2)         
  Component:  distro     |     Version:                               
 Resolution:             |    Keywords:  rainbow-integration, security
Next_action:  never set  |    Verified:  0                            
  Blockedby:             |    Blocking:                               
-------------------------+--------------------------------------------------

Comment(by mtd):

 Replying to [comment:12 cscott]:
 > mtd: can I get some more information about how your patch is expected to
 work?

 This ticket observes that olpc-dm owns tty1 and that isn't desired.  The
 way to relinquish ownership of a tty whilst forking is clearly laid out as
 steps 2 and 3 in  http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16
 , and not-so-clearly laid out as a consequence of doing step 6 (which is
 what wasn't being done by olpc-dm.c, on purpose (see my answer to your
 "Why is [this/step 6] the right thing to do", belo), and what my patch
 enables).

 > Why were we originally setting tty to tty2?

 I don't know.  AFAICS from the git history we've never changed that line
 of code.  But I know we're supposed to be running X on tty3, right?  And
 my F9 gdm-binary / gdm-simple-slave do something very similar to that.
 You'll forgive me if I skimp on answering this historical question to draw
 your attention to my answer to your final two questions.

 > If this was previously completely broken, why didn't we notice?

 Well this ticket's 7 months old.  And one wouldn't notice it being
 "broken" unless you try to use one of tty{1,2}.  ibid. re historical
 questions before my time.

 >  Why is removing the assignment of controlling tty the right thing to
 do?

 Because we don't know what tty we're started on, and we should be started
 on tty3.  Starting on tty3 is right by definition (I suppose, though I
 don't have a Sugar/XO design document in mind).  For a stronger argument:
 because we don't know what tty we're started on, and we *should* be
 started on a well known tty (no design document references again, sorry,
 but this seems really common sense to me).

 >  If I understand correctly, this code was originally lifted from gdm --
 why is this the right thing for gdm to do, but not for us?

 I'm not totally clear on my olpc-dm was meant to do, but just that the
 problem - olpc-dm should not grab the same tty as another mingetty does -
 is solved.  Of course more problems could be introduced in some subtle
 ways, so I'm glad people more aware of olpc-dm's goals are thinking about
 this.

 > Removing code like this makes me very nervous absent a good explanation.

 I understand, but even if you want to believe that tty2 was chosen on
 purpose and that olpc-dm should be running on the same tty as one of the
 XO's mingetty's, consider the two - three, by some count - large scary
 comments in olcp-dm.c near my patch's changed lines, saying, roughly "well
 this area of code might be causing [exactly the brokenness mtd's patch
 fixes]".  Just as some small comfort.

 I found re-visiting how to properly double fork (which, FTR, I believe
 login.c's code *was* achieving for its use case, but ours is different
 because we've not got ourselves a good tty from mingetty or similar) at
 http://www.steve.org.uk/Reference/Unix/faq_2.html#SEC16 especially fun, so
 I welcome any illuminations about what this code should (or even was
 intended to ;)) be doing and don't pretend I know all the context in which
 my patch would be executed.

 That being said, I'm pretty unconvinced of any arguments that tty2 was
 chosen explicitly and that the behavior of grafting on to a mingetty-
 managed terminal is desirable.

-- 
Ticket URL: <http://dev.laptop.org/ticket/5705#comment:13>
One Laptop Per Child <http://laptop.org/>
OLPC bug tracking system