John Summerfield wrote:
I'm looking at CentOS5 on a PC. I'm running inside X (xorg). Oh, just in case it matters, I'm running KDE. Who knows, it could be different in GNOME. 08:42 [sum...@bobtail ~]$ \ls -l $(tty) crw------- 1 summer tty 136, 17 Mar 4 20:24 /dev/pts/17 20:24 [sum...@bobtail ~]$ so there is a problem there. Inside screen, each session gets its own tty. The tty is as above except group-writable. Directly logged into a console, it's owner rw, group w. Connecting via ssh: [r...@bobtail ~]# \ls -l $(tty) crw--w---- 1 root tty 136, 22 Mar 4 20:30 /dev/pts/22 [r...@bobtail ~]# HOWEVER, I logged in as root, used "su - summer" and it's all working, until I do this: 20:33 [sum...@bobtail ~]$ id -Gn >$(tty) -bash: /dev/pts/22: Permission denied 20:34 [sum...@bobtail ~]$ The reason is that the file handles are inherited, and while they remain open the original permissions apply. So the tty command tells you whether you have a terminal, but you need to test whether you can read/write if before opening new handles. sudo is setuid root, so _it_ is okay.
That's what I was referring to ! The problem is not that the file handle remains open (you open a new one when you do "> $(tty)")... Actually, it *NEEDS* to maintain the file handle opened, otherwise, you wouldn't be able to write to your own stdout and read from stdin (those are the ones opened by root.. well before su fires up !) The problem (in that particular case) is that your user does not seem to be part of the 'tty' group ! Other people may experience other problems depending on the default ownerships & permissions given to terminals by the pts/pty terminal creator... (your case was under ssh.. X terminal may be different, and of course, from the system console, it's going to be another different case.. Basically, after su, ownership & permission of the process' controlling terminal is pretty much unpredictable - and *THAT* is the root cause of the problem I was talking about). And... su can't change the ownership of the tty (I mean, the ownership of the /dev node which represent the process' controlling terminal) - simply because it wouldn't be able to switch it back to the original owner upon exit of the shell (su does an exec() of the shell after having relinquished setuid rights.. so it'd be too late - not to mention it may even never be notified (Signal 9)). However... it could do something else : create a node (mknod) with the same major/minor as the process controlling terminal in /tmp (while still being user 0) with ownership given to the new user (the one being su'ed to) - and eventually giving the responsability to init to clear up any leftover (but that would also require the shell to start a new process group..).. This has unfortunately several other disadvantages : utmp/wtmp entries are going to be somewhat warped, msgon/msgoff may still be bypassed, etc, etc.. The problem I was referring to about 'screen', is that in my experience, 'screen' seems to be wanting to do some stuff to the controlling terminal node that it's not permitted to do unless it can open it independently or maybe be the owner. PS : What I mean by 'process controlling terminal' is, after a call to setsid(), the 1st terminal device file opened by a process with the O_NOCTTY flag cleared. Basically, the name of the node is given by the 'tty' command and signals generated by special keys (like ^C.. but the particular character depends on the stty settings) on that terminal are sent to those processes that have this terminal as a controlling terminal. --Ivan ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to lists...@vm.marist.edu with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
smime.p7s
Description: S/MIME Cryptographic Signature