Hi Folks
http://bugme.osdl.org/show_bug.cgi?id=1045
I found that devfs and traditional pty's don't work properly with
2.6-test4 and a lot of previous versions. Note im talking about
traditional pty's not UNIX98 which need devpts mounted.
The pty slave devices do not appear in devfs. They should be
/dev/pts/s* and symbolic links from /dev/pty* into /dev/pts/s*. But
these are all missing. So programs like ripperx which use a pty to
control cdparanoia don't work.
I've attached two possible patches to the bugzilla bug. The first one
causes the slave devices to be created in devfs at start up. The
second one makes it work more like 2.4 when the slave device is only
created when the master device is opened.
Both patches suffer from a problem. The slave is always only RW
root. 2.4 sets the owner of the slave to that of the process opening
the master. I cannot see a way to make this happen with 2.6-test.
Im open for suggestions as to the correct way to fix this.
Thanks
Andrew
Christoph Hellwig <[email protected]> wrote:
>
> > IOW: we broke it. Have you any theory as to which change caused this?
>
> That's the magic use uid/gid of the process calling devfs_Register flag
> I killed. With a big HEADSUP and explanation on lkml..
So what is the impact here? That libc5 will break if the user is using
devfs and old-style pty's?
Christoph Hellwig <[email protected]> wrote:
>
> On Tue, Sep 02, 2003 at 12:42:12PM +0200, Andrew Lunn wrote:
> > I've attached two possible patches to the bugzilla bug. The first one
> > causes the slave devices to be created in devfs at start up. The
> > second one makes it work more like 2.4 when the slave device is only
> > created when the master device is opened.
>
> The first patch looks okay.
But what about this:
> > Both patches suffer from a problem. The slave is always only RW
> > root. 2.4 sets the owner of the slave to that of the process opening
> > the master. I cannot see a way to make this happen with 2.6-test.
>
> Well, that's why we have UNIX98 ptys. My preferred fix for this
> issue would be to just axe traditional ptys, although this would probably
> make it us incompatible with libc5.
Unless we made an explicit decision to kill off old-style ptys (and we did
not do that), they should continue to work as in 2.4, yes?
IOW: we broke it. Have you any theory as to which change caused this?
On Tue, Sep 02, 2003 at 10:21:41AM -0700, Andrew Morton wrote:
> > > Both patches suffer from a problem. The slave is always only RW
> > > root. 2.4 sets the owner of the slave to that of the process opening
> > > the master. I cannot see a way to make this happen with 2.6-test.
> >
> > Well, that's why we have UNIX98 ptys. My preferred fix for this
> > issue would be to just axe traditional ptys, although this would probably
> > make it us incompatible with libc5.
>
> Unless we made an explicit decision to kill off old-style ptys (and we did
> not do that), they should continue to work as in 2.4, yes?
They work as they do in 2.4 and 2.6 (and any previous kernel) without
devfs, remember the pt_chown pain?
There's no point in emulating half of the UNIX98 pty semantics
in devfs when we have UNIX98 ptys that do it right anyway.
> IOW: we broke it. Have you any theory as to which change caused this?
That's the magic use uid/gid of the process calling devfs_Register flag
I killed. With a big HEADSUP and explanation on lkml..
On Tue, Sep 02, 2003 at 10:43:40AM -0700, Andrew Morton wrote:
> > That's the magic use uid/gid of the process calling devfs_Register flag
> > I killed. With a big HEADSUP and explanation on lkml..
>
> So what is the impact here? That libc5 will break if the user is using
> devfs and old-style pty's?
If he removed the pt_chown logic that is present with a stock libc5,
yes. I wouldn't know why someone would do that, though.
That's why I'm really keen on knowing how the system of the bugreporter
looks - this shouldn't happen without a very strange setup.
On Tue, Sep 02, 2003 at 12:42:12PM +0200, Andrew Lunn wrote:
> I've attached two possible patches to the bugzilla bug. The first one
> causes the slave devices to be created in devfs at start up. The
> second one makes it work more like 2.4 when the slave device is only
> created when the master device is opened.
The first patch looks okay.
> Both patches suffer from a problem. The slave is always only RW
> root. 2.4 sets the owner of the slave to that of the process opening
> the master. I cannot see a way to make this happen with 2.6-test.
Well, that's why we have UNIX98 ptys. My preferred fix for this
issue would be to just axe traditional ptys, although this would probably
make it us incompatible with libc5.
Why aren't you using the new-style ptys?
> Well, that's why we have UNIX98 ptys. My preferred fix for this
> issue would be to just axe traditional ptys, although this would probably
> make it us incompatible with libc5.
>
> Why aren't you using the new-style ptys?
Ripperx, the program that is failing, is not mine. I have no control
over what sort of pty it uses. Im sure there are other programs with
use traditional pty's as well.
Andrew
> That's why I'm really keen on knowing how the system of the bugreporter
> looks - this shouldn't happen without a very strange setup.
I've attached to the bugzilla bug my .config (its actually for -test2)
and an ls -la /dev/pt*
Is there anything else you want to know?
Andrew
On Tue, Sep 02, 2003 at 08:16:54PM +0200, Andrew Lunn wrote:
> > That's why I'm really keen on knowing how the system of the bugreporter
> > looks - this shouldn't happen without a very strange setup.
>
> I've attached to the bugzilla bug my .config (its actually for -test2)
> and an ls -la /dev/pt*
>
> Is there anything else you want to know?
That doesn't really help - if an application opens old-style pty's
directly the permissions can't work. IF you care for them fill a
bugreport to ripperx that it should use openpty() from libc which
will fix the problem automatically.
Until then we should apply your patch to create the slaves on init
so the behaviour is consistant with 2.4 and 2.6 without devfs.
I was just wondering whether you were using an acient / stripped
down libc with the pt_chown helper removed.
On Tue, Sep 02, 2003 at 07:29:29PM +0100, Christoph Hellwig wrote:
> On Tue, Sep 02, 2003 at 08:16:54PM +0200, Andrew Lunn wrote:
> > > That's why I'm really keen on knowing how the system of the bugreporter
> > > looks - this shouldn't happen without a very strange setup.
> >
> > I've attached to the bugzilla bug my .config (its actually for -test2)
> > and an ls -la /dev/pt*
> >
> > Is there anything else you want to know?
>
> That doesn't really help - if an application opens old-style pty's
> directly the permissions can't work. IF you care for them fill a
> bugreport to ripperx that it should use openpty() from libc which
> will fix the problem automatically.
OK. Will do.
> I was just wondering whether you were using an acient / stripped
> down libc with the pt_chown helper removed.
Nope. A pritty normal Debian Woody system.
Thanks
Andrew
Christoph Hellwig writes:
> On Tue, Sep 02, 2003 at 10:43:40AM -0700, Andrew Morton wrote:
>>> That's the magic use uid/gid of the process calling
>>> devfs_Register flag I killed. With a big HEADSUP
>>> and explanation on lkml..
>>
>> So what is the impact here? That libc5 will break if
>> the user is using devfs and old-style pty's?
>
> If he removed the pt_chown logic that is present with a
> stock libc5, yes. I wouldn't know why someone would do
> that, though.
The problem may be more serious. There are lots of
apps that use the old-style PTYs w/o any libc help.
a. because that's the historic BSD way
b. so the user can choose a specific pty
For example, there's a "remserial" program
that abuses a PTY for giving access to a
serial port over the network. Apps trying to
use the port work pretty well, without any need
for source code changes or new kernel drivers.
On Tue, Sep 02, 2003 at 10:52:47PM -0400, Albert Cahalan wrote:
> The problem may be more serious. There are lots of
> apps that use the old-style PTYs w/o any libc help.
That's not a problem, just bad design. It continues to work as always,
i.e. you don't get an automic chown. For that you either needs the
libc interface with the pt_chown helper of UNIX98 ptys.