Ivan Warren wrote:
John Summerfield wrote:
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?
Sorry.. I shouldn't have said 'problem'.
_I_ said, and mean, _problem_.
I meant 'reason'.. I was just giving what I feel is the correct
technical 'reason' why attempting to write to the file node returned by
the "tty" command is giving a "permission denied" error.
You were indicating that behavior was caused by the file node still
having an opened file descriptor opened by root. I believe this is not
the reason.
In this discussion, "file" includes special files such as devices.
In the case I illustrated, the behaviour I described is what is defined
as happening. A process created by fork() inherits open file handles.
exec(), to run another program, does not _necessarily_ close open file
handles. As I recall it, the default behaviour is to inherit them.
Since a process running as a user cannot open a file owned by root and
with permissions 0600, the only reason it can read/rite to such a file
is that it's inherited the handles.
If the permissions are 0660, 0640 or 06200, and the file owned by group
"tty" and lots of people are in group "tty," then I smell a security
problem.
Do you?
Rather, the reason is that the user which you "su" to does not have
permission to open in write mode the file node which is returned by the
'tty' command because the node ownership and permission is preventing
you from doing so.
we agree that permissions prevent it. However, it's clear the user can
read/write the terminal.
That was my original point in discussing the differences between "su -"
(which doesn't change tty ownership) and "login" (which does).
You are of course correct that adding non privileged arbitrary users to
the tty group could be a security issue.
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.
And my observation is that "screen" is attempting at some point to
re-open the process controlling terminal file node in order to ensure
any redirection does not affect front-end 'screen' operations (as
I wonder why it does that, rather than check (with isatty(), fstat() or
ttyname()), then belch if it doesn't like what it sees?
https://savannah.gnu.org/bugs/?25214
I've added comments, it's possible to do so anonymously.
opposed to back-end which is indeed performed through the creation of
ptys which DO have the appropriate ownership and permissions) - and that
this fails when you su from root to a non-root user for the reason
described above. This may be dependent on the version of the "screen"
package.. But this is what I get :
deb64-1:~# su - ivan
i...@deb64-1:~$ screen
Cannot open your terminal '/dev/pts/2' - please check.
Ah, now I see. I don't think I've ever tried that combination of actions.
I have reproduced the same behaviour with sudo.
This gets around it:
chmod g+wr $(tty)
i...@deb64-1:~$ ls -l $(tty)
crw------- 1 root tty 136, 2 2009-03-05 12:46 /dev/pts/2
i...@deb64-1:~$ dpkg -l screen
<snip/>
ii screen 4.0.3-11
terminal multiplexor with VT100/ANSI terminal emulation
i...@deb64-1:~$
Note that the above is not restricted to Linux on z.. and not even
I never thought that, such a difference would be a big fat BUG.
restricted to linux altogether. Other Posix systems (Un*x, AIX, etc..)
display the same difference between "su -" and "login".
Hmm.
--
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
