Borsenkow Andrej writes:
> On СбÑ?, 2002-02-16 at 03:48, Martin MaÄ?ok wrote:
> > Hi,
> > when I run rxvt/xterm/konsole/gnome-terminal, my pseudoterminals at
> > /dev/pts/* does not own group "tty" so I cannot use
> > % mesg y
> > mesg: error: tty device is not owned by group `tty'
> >
> > and users cannot "talk" to each other.
> >
> > When I log on text console, permission for /dev/vc/* are owned by
> > group tty so talk here works.
> >
> > Is it problem with devfs? pam? init?
> >
>
> Well, I am really confused here.
>
> - permissions for console (/dev/tty*) are (most probably) set either by
> mingetty or by login. Neither pam nor devfsd are responsible for them.
>
> - Mandrake by default is using devpts so you could specify group by
> adding gid=5 in /etc/fstab to /dev/pts line. You could also change modes
> from default 644 if you want
>
> - still devfs documentation tells us we should not use devpts with
> devfs; and I am not sure who wins. pty.c registers /dev/pts/? with
> current owner and 600 permissions; and here I have
>
> {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?).
> - and /etc/devfsd.conf tells us we must not fiddle with /dev/pt{s,y}
> permissions.
Well, it doesn't quite say that. What it says is that you don't want
to have permissions persistence for /dev/pt{s,y} devices. That doesn't
mean you can't or shouldn't have a PERMISSIONS action.
> So could anybody give ultimate answer on
>
> - should devpts be used in presence of devfs?
No.
> - how to manage permissions of pts - i.e. why they cannot be managed by
> devfsd?
As Russell said in his follow-up, use a PERMISSIONS action on the
REGISTER event.
Regards,
Richard....
Permanent: rgooch@xxxxxxxxxxxxx
Current: rgooch@xxxxxxxxxxxxxxx
|