Ivan Warren wrote:
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
It's not. Is yours? If the tool you use to create user accounts doesn't
make it so (or at least suggest it should be so), and you don't know to
do it, it's not done.
However, setting ownership at login makes it so you can open files to it
and read/write.
OTOH, if I'm in the tty group, then I can write to any tty that is group
writable.
Do you smell a security problem here?
depending on the default ownerships & permissions given to terminals by
the pts/pty terminal creator... (your case was under ssh.. X terminal
I gave several examples. X is different.
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.
My observation is that screen creates pseudo ttys for all its sessions,
sets TERM=screen and maps what comes back from the session to the tty
_it_ writes to, the one active before it was started.
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
--
Cheers
John
-- spambait
1aaaa...@coco.merseine.nu z1aaaa...@coco.merseine.nu
-- Advice
http://webfoot.com/advice/email.top.php
http://www.catb.org/~esr/faqs/smart-questions.html
http://support.microsoft.com/kb/555375
You cannot reply off-list:-)
----------------------------------------------------------------------
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
