On σΒΤ, 2002-02-23 at 20:37, Richard Gooch wrote:
> Borsenkow Andrej writes:
> > > > 
> > > >  {pts/1}% ll /dev/pts
> > > > ΠΈΡ'ΠΎΠ³ΠΎ 0
> > > > crw--w----    1 bor      bor      136,   0 ΠΗЁЁ 16 16:11 0
> > > > crw-------    1 bor      bor      136,   1 ΠΗЁЁ 16 17:05 1
> > > > crw-------    1 bor      bor      136,   2 ΠΗЁЁ 16 17:03 2
> > > > crw-------    1 bor      bor      136,   3 ΠΗЁЁ 16 17:04 3
> > > > 
> > > > that looks like pts/0 got permissions from devpts and others from devfs
> > > > because default mount for devpts here is 640
> > > 
> > > I doubt that. More likely some programme changed the permissions for
> > > pts/0 (perhaps xconsole or th Gnome equivalent?).
> > 
> > I booted without mounted devpts and all of them have the same
> > permissions:
> > 
> > {pts/2}% LANGUAGE=en LC_TIME=en ll /dev/pts
> > total 0
> > crw-------    1 bor      bor      136,   0 Jan  1  1970 0
> > crw-------    1 bor      bor      136,   1 Feb 18 22:51 1
> > crw-------    1 bor      bor      136,   2 Feb 18 22:55 2
> 
> Interesting.
> 
> > may be there are different ways to open pty and they take different
> > paths.
> 
> Could be. If so, it's most likely to be in the glibc PTY allocation
> code. It wouldn't surprise me, considering how much bloated shit is
> already in glibc. I know that they had hard-wired Unix98 PTY
> allocation to devpts at one point, and needed a patch to support devfs
> as well (which was added). Instead of their pointless hard-wiring,
> they could have just dropped that code and it would work automatically
> irrespective of the FS type.
> 
> > But this imply that we really should not use devpts due to
> > possiblilty of permissions not being applied.
> 
> Looks like it. Sigh. It would be nice if someone could do some
> stracing to figure out what was being done behind the covers.
>

Ouch. Sorry, it lingered in unsent messages, I forgot to remove it.

To close the theme, permissions are alike both with and without devpts
(at least using kernel and glibc shipped by current Mandrake cooker). In
the very first case I presume permissions were modified by some process.
It means that devfsd.conf mods will work and the only drawback is user
confusion if they will try to modify permissions via devpts mount
options (because it seems to be completely ignored).

-andrej

Reply via email to