From: Alan C. <al...@lx...> - 2012-06-07 10:49:00
|
> > I really don't get it. You have not broken anything new. Only > > not fixed all of the problems. Current code does not work for "non-tty0 > > terminals" as well right? > > No, it works fine. Not really. You happen to be lucky. Anyway with no tty port the UML code will soon cease to function completely so a solution of some sort is needed. > > I don't see Alan's comment at all. This is not a regression it was always > > like that. Ever since Fedora was working on UML, But these fixes are real > > live regression crashes. > > > > And I don't see the all "leaving other vendors systems insecure". It just > > a freaking UML tty. You need to be root 5 times before you have access > > to all these, and it's only the UML that's compromised not the "all system" > > And surely the current plain tty0 crash is much less secure then this thing. > > The "TTY problem" is not UML specific. That one is. The console driver handles stuff its own way and differently. It's eventually got to tackle the same problem. I still think we ought to be able to solve it cleanly. It's a case of getting the tests right so that we allow for the misbehaviour util-linux does. As of itself util-linux behaviour doesn't appear to be something we can't permit as the open vhangup sequence means the file handle that is left from before the vhangup due to util-linux misbehaving is a hung-up fd so cannot affect the tty. UML is a good test case for fixing this properly because it's got almost no users, and those it has are fairly technical 8) Alan |
From: Boaz H. <bha...@pa...> - 2012-06-07 13:41:28
|
On 06/07/2012 01:52 PM, Alan Cox wrote: >> No, it works fine. > > Not really. You happen to be lucky. Anyway with no tty port the UML code > will soon cease to function completely so a solution of some sort is > needed. > This is what I understood. That mainline code moved so far that the current UML driver was too far behind to properly function and *completely* broke. If only breakage with new UM-TTY code is old util-linux. And we have a ready made patch for it. Would you please reconsider, and point the util-linux users to the fixing patch. Because as it stands: Current code: util-linux - works FC12-17 - Broken (Patch *not* available) Debain based - works New code: util-linux - Broken, patch available FC12-15 - Works (with issues) Debain based - works So it is not like I'm sacrificing util-linux People completely, but I am totally sacrificing FC People by not committing. Please reconsider, unless you have a patch for me for FC systems that I can apply so I can use the old code. Thanks again for everything, so far Boaz |
From: Richard W. <ri...@no...> - 2012-06-07 15:18:48
Attachments:
signature.asc
|
Alan, Jiri! If I omit ->hangup(), mingetty (And all other getty implementations) are unable to open /dev/ttyX. open() returns -EIO. Currently I'm testing it on FC12. Also if I do something like "echo foo >/dev/tty1" it fails with -EIO. And now the strange thing, opening and writing an unknown (unknown to this upstart rubbish) tty works. E.g.: echo foo >/dev/tty10. Any ideas what's going wrong? Thanks, //richard |
From: Alan C. <al...@li...> - 2012-06-07 16:21:42
|
On Thu, 07 Jun 2012 17:18:37 +0200 Richard Weinberger <ri...@no...> wrote: > Alan, Jiri! > > If I omit ->hangup(), mingetty (And all other getty implementations) > are unable to open /dev/ttyX. open() returns -EIO. > Currently I'm testing it on FC12. > Also if I do something like "echo foo >/dev/tty1" it fails with -EIO. > And now the strange thing, opening and writing an unknown (unknown to > this upstart rubbish) tty works. E.g.: echo foo >/dev/tty10. > > Any ideas what's going wrong? Yes I know exactly what is going on. However getting a more tolerant behaviour is going to take a couple more kernels. Alan |
From: Richard W. <ri...@no...> - 2012-06-07 16:32:55
Attachments:
signature.asc
|
Am 07.06.2012 18:37, schrieb Alan Cox: > Yes I know exactly what is going on. However getting a more tolerant > behaviour is going to take a couple more kernels. > So, then please tell me what's the proper way to fix the UML console driver? - tty_port plus ->hangup() works only with a patched util-linux - tty_port without ->hangup() seems to work only if *getty does not call vhangup() Thanks, //richard |
From: Alan C. <al...@li...> - 2012-06-07 16:34:44
|
On Thu, 07 Jun 2012 18:32:42 +0200 Richard Weinberger <ri...@no...> wrote: > Am 07.06.2012 18:37, schrieb Alan Cox: > > Yes I know exactly what is going on. However getting a more tolerant > > behaviour is going to take a couple more kernels. > > > > So, then please tell me what's the proper way to fix the UML console > driver? > > - tty_port plus ->hangup() works only with a patched util-linux > - tty_port without ->hangup() seems to work only if *getty does not > call vhangup() There isn't a nice one. It'll have to wait until 3.6/7 or so to get fixed nicely and it won't backport either. Alan |
From: Richard W. <ri...@no...> - 2012-06-07 16:41:29
Attachments:
signature.asc
|
Am 07.06.2012 18:50, schrieb Alan Cox: > On Thu, 07 Jun 2012 18:32:42 +0200 > Richard Weinberger <ri...@no...> wrote: > >> Am 07.06.2012 18:37, schrieb Alan Cox: >>> Yes I know exactly what is going on. However getting a more tolerant >>> behaviour is going to take a couple more kernels. >>> >> >> So, then please tell me what's the proper way to fix the UML console >> driver? >> >> - tty_port plus ->hangup() works only with a patched util-linux >> - tty_port without ->hangup() seems to work only if *getty does not >> call vhangup() > > There isn't a nice one. It'll have to wait until 3.6/7 or so to get > fixed nicely and it won't backport either. > Hmm, that's odd. What about the not nice ways? Having a ugly driver until 3.7 is better than having no driver... I'm wondering why does drivers/tty/vt/vt.c work? Can't I model the UML driver after it? Thanks, //richard |
From: Alan C. <al...@lx...> - 2012-06-07 17:22:56
|
> What about the not nice ways? > Having a ugly driver until 3.7 is better than having no driver... If you are willing to go do the work then yes. > I'm wondering why does drivers/tty/vt/vt.c work? > Can't I model the UML driver after it? Possibly although the vt driver has its own locking model to watch out for. Alan |
From: Karel Z. <kz...@re...> - 2012-07-12 14:49:44
|
On Tue, Jun 05, 2012 at 05:17:19PM +0200, Karel Zak wrote: > On Tue, Jun 05, 2012 at 02:20:38PM +0200, Richard Weinberger wrote: > > Am 05.06.2012 13:15, schrieb Alan Cox: > > > Actually I'd prefer a clever solution which can spot all the fds are the > > > same process so we can keep compatibility but I've not found a sensible > > > way to do that. > > > > Me too. > > > > For UML users the current situation is odd. > > They have to select between: > > - Having a UML that crashes randomly on some distros. > > - Applying the TTY fix and break login on every distro that uses util-linux's login. > > - Applying the TTY fix and patch util-linux too. > > I'll follow kernel... so if close-before-vhangup is preferred way > than I'll modify util-linux login(1). No problem. I just fixed login(1) and agetty (--hangup option). The change will be available in util-linux v2.23 (rc1 will be this month). Karel -- Karel Zak <kz...@re...> http://karelzak.blogspot.com |
From: Richard W. <ri...@no...> - 2012-07-12 15:02:00
|
Am Thu, 12 Jul 2012 16:49:28 +0200 schrieb Karel Zak <kz...@re...>: > I just fixed login(1) and agetty (--hangup option). The change will > be available in util-linux v2.23 (rc1 will be this month). > Thank you! //richard |