Re: bug in talk-server + /dev/pts/?
Hi, # Uncomment the following if you want to set the group to tty for the # pseudo-tty devices. This is necessary so that mesg(1) can later be used # to enable/disable talk requests and wall(1) messages. REGISTER ^pty/s. PERMISSIONS -1.tty 0600 REGISTER ^pts/.* PERMISSIONS -1.tty 0600 which suggests that by default devfsd is trying to do the right thing. Well then I'm not sure why the permissions are wrong on your machine. devfsd is properly setting the permissions for me. Have you tried deleting the contents of your /lib/dev-state directory and rebooting? It shouldn't be trying to do any thing with the tty's but *shrug* it's all I can think of. It turned out that devfs was not running; on oldworld BootX login's chkconfig --on devfsd is useless as the partitions are not mounted with devfs [no /dev/.devfsd file]. One must explicitly add devfs=mount to the kernel arguments. This has the added benefit of making the tun module do something useful for MOL [though it gets the link wrong /dev/net/tun - misc/net/tun should go to /dev/misc/net/tun], and the evdev module allows /dev/input/keyboard for use with pbbuttonsd, which is nice for us laptop users. Upshot: use devfs to get some advanced functionality, you will need kernel argument devfs=mount to do this. Q.
Re: bug in talk-server + /dev/pts/?
On Mon, Apr 15, 2002 at 02:08:21AM -0400, Quentin Mason wrote: I usually have mesg y in the interactive section of my login scripts so that people may talk or ytalk to me when I am interactively using that login [cf mesg n for remote batch jobs]. On my new vanilla Mandrake 8.2\beta2 install mesg y fails in bash, tcsh etc at all times. The error is: mesg: error: tty device is not owned by group `tty' and sure enough /dev/pts/? is owned by user.user not user.tty; mesg n is fine however. I'm pretty sure this is a symptom of msec being run at a high security level. Try reading man msec and it's accompanying documents. There is a way to override the permissions that is causing your issue. Or you can just lower your security level. I have mine on level 3 and mesg y and mesg n works just fine. You can find out your current level via: grep SECURITY /etc/sysconfig/system To change it just run: msec X Where X is a level (0-5). The higher the number the more secure. Incidentally the talk issue is a known issue of running at a higher security level and it was determined that it was an acceptible problem because very few people that use that feature also run at high security levels. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? - Ghandi
Re: bug in talk-server + /dev/pts/?
Hi, On Mon, Apr 15, 2002 at 02:08:21AM -0400, Quentin Mason wrote: I usually have mesg y in the interactive section of my login scripts so that people may talk or ytalk to me when I am interactively using that login [cf mesg n for remote batch jobs]. On my new vanilla Mandrake 8.2\beta2 install mesg y fails in bash, tcsh etc at all times. The error is: mesg: error: tty device is not owned by group `tty' and sure enough /dev/pts/? is owned by user.user not user.tty; mesg n is fine however. I'm pretty sure this is a symptom of msec being run at a high security level. Try reading man msec and it's accompanying documents. There is a way to override the permissions that is causing your issue. Or you can just lower your security level. I have mine on level 3 and mesg y and mesg n works just fine. You can find out your current level via: grep SECURITY /etc/sysconfig/system I am on level 2 [internet access is through a firewall], so it is lower than yours. I could not find any info in /usr/share/doc/msec-0.19, /var/lib/msec/security.conf or any of the perms files in /usr/share/msec, man msec or man mseclib Incidently my vanilla /etc/devfsd.conf file contains: # Uncomment the following if you want to set the group to tty for the # pseudo-tty devices. This is necessary so that mesg(1) can later be used # to enable/disable talk requests and wall(1) messages. REGISTER ^pty/s. PERMISSIONS -1.tty 0600 REGISTER ^pts/.* PERMISSIONS -1.tty 0600 which suggests that by default devfsd is trying to do the right thing. Incidentally the talk issue is a known issue of running at a higher security level and it was determined that it was an acceptible problem because very few people that use that feature also run at high security levels. Fair enough. There is still the problem with 2 copies of the the config file though. Q.
Re: bug in talk-server + /dev/pts/?
On Mon, Apr 15, 2002 at 11:52:29AM -0400, Quentin Mason wrote: I am on level 2 [internet access is through a firewall], so it is lower than yours. I could not find any info in /usr/share/doc/msec-0.19, /var/lib/msec/security.conf or any of the perms files in /usr/share/msec, man msec or man mseclib Incidently my vanilla /etc/devfsd.conf file contains: # Uncomment the following if you want to set the group to tty for the # pseudo-tty devices. This is necessary so that mesg(1) can later be used # to enable/disable talk requests and wall(1) messages. REGISTER ^pty/s. PERMISSIONS -1.tty 0600 REGISTER ^pts/.* PERMISSIONS -1.tty 0600 which suggests that by default devfsd is trying to do the right thing. Well then I'm not sure why the permissions are wrong on your machine. devfsd is properly setting the permissions for me. Have you tried deleting the contents of your /lib/dev-state directory and rebooting? It shouldn't be trying to do any thing with the tty's but *shrug* it's all I can think of. -- Ben Reser [EMAIL PROTECTED] http://ben.reser.org What difference does it make to the dead, the orphans, and the homeless, whether the mad destruction is wrought under the name of totalitarianism or the holy name of liberty and democracy? - Ghandi
