I think it is a security issue, because that "Aside from the potential of my non-root user account being compromised" can be rather large.
But there are other increased risks beyond that. For example, you've now opened yourself up to a theoretical exploit which allows one to change permissions in the screen socket dir (/var/run/screen
on my system, but sometimes /tmp
is used). That exploit now has an path to getting root, which it might not otherwise.
sudo
has other advantages, if you can train yourself to use it for each command rather than doing sudo su -
. It logs actions (which, unless you're logging remotely, doesn't meaningfully increase security, but does give you a trail of what you've done). And it helps prevent accidents by requiring intentional escalation for each command, rather than switching to an entirely-privileged session.
The flip-flopping between "must have mode 777" and "must have mode 775" is caused by strace
.
screen
is usually a setuid or setgid program. It gains extra privileges when it is executed, which is uses to create socket files and/or modify utmp.
When a process is being traced, setuid and setgid are disabled. The tracing process, controlled by the less-privileged user, can take over the traced process so it must run without its extra privileges to avoid giving the original user too much power.
screen
detects whether it is being run with setuid privileges, setgid privileges, or neither, and adjusts its expectation of the directory permissions accordingly.
So this creates a class of problems that can't be easily debugged with strace
.
But if you're root, there is a workaround! If the tracing process is running as root, then the traced process can gain privileges normally. So here's what you do:
- Open 2 new terminals
- In the first terminal, log in to the remote machine as root
- In the second terminal, log in to the remote machine as normal user
- Use
ps
to get the PID of the normal user's shell process in the second terminal
- In the first terminal, run
strace -f -p SHELLPID
- In the second terminal, run screen and watch it fail
- In the first terminal, you now have the strace log you need to find out what's really wrong.
The key addition to the strace
command is the -f
option, which tells it to trace child processes. You need it to trace the screen that will be a child of the shell process you specified with -p
.
I also like to use -ff
and specify an output file with -o
, as in
strace -ff -o /tmp/screentrace -p SHELLPID
which will create a separate output file for each child process. Afterward you read them with less /tmp/screentrace*
and the result is usually cleaner than what you get using a single -f
.
UPDATE
Now that I've seen the strace output, I don't know exactly what went wrong, but this line is the most surprising thing in the trace:
chown("/dev/pts/2", 1002, 5) = -1 EPERM (Operation not permitted)
A few lines earlier, it created a pty, which was revealed by TIOCGPTN
to be number 2.
open("/dev/ptmx", O_RDWR) = 5
...
ioctl(5, TIOCGPTN, [2]) = 0
stat("/dev/pts/2", {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0
But it was unable to chown it. I don't know why that chown would fail, but the chown failure does give a plausible reason why screen gave up. You can get a little more information by adding -v
to the strace options, and looking at the stat
after the TIOCGPTN
to see who owns the /dev/pts/
entry.
Best Answer
Your system, once
screen
detaches, destroys thepts
, and for some reason recreates it, if I understand correctly howudev
is handling things on your system.udev
is the subsystem that controls the creation and destruction of devices in /dev, which is a dynamically generated filesystem.pts
creation/destruction is handled byptmx
, which is used to create pseudo-terminal master/slave pairs.pts/*
is the slave of the respectivePTM
, or pseudo-terminal master. As such, any permissions modifications that you see are a direct result of the destruction and creation of said device nodes, rather than modification. As for the date of the file, since the device nodes are clones, it's likely that the original used to create these nodes had a creation date of the time that you see in yourls
output.man ptmx
-- Describes how ptmx creates new pts pseudo terminal device nodes.What I don't understand is why there is a difference between how your system behaves versus how mine behaves with regard to
/dev/pts/
*. I do not experience perceived perms changes to devices; They either disappear entirely which is as it should be, or the perms do not change regardless of my actions (e.g., detaching screen, the device stays, and does not get destroyed/recreated.). Not only that, but the dates associated with my newly createdpts/*
devices are the current date.One possibility is that the VPS you're using has something to do with this behavior. For example, I can't perform a dist-upgrade on my VPS, since the system they utilize only allows for one kernel version, the one they've hacked and put in place. The kind of restrictions that prevent you from updating your own kernel could also impact the functionality of other sub-systems. That's just speculation though, but it would make sense.
It could also just be a difference in how udev is configured.
Revision 3, with a lot of help from Gilles. ;)