Try using screen -RR.
Example:
$ screen -ls
There are screens on:
5958.pts-3.sys01 (08/26/2010 11:40:43 PM) (Detached)
5850.pts-1.sys01 (08/26/2010 11:40:35 PM) (Detached)
2 Sockets in /var/run/screen/S-sdn.
Note that screen 5958 is the youngest. Using screen -RR connects to screen 5958. The -RR options is somewhat further explained in the documentation for -d -RR.
-d -RR Reattach a session and if necessary detach or create it. Use
the first session if more than one session is available.
Another trick I often use is to use -S to give the screen a tag/label. Then you can reattach using that tag without having to remember what was happening in each screen if the list gets unwieldy.
Example (Launch screens for vim and curl):
$ screen -dm -S curl
$ screen -dm -S vim
$ screen -list
There are screens on:
11292.vim (08/27/2010 12:02:53 AM) (Detached)
11273.curl (08/27/2010 12:01:42 AM) (Detached)
Note: The -dm option was just used to start a detached screen
And then, at a later date, you can easily reconnect using the tag curl.
# screen -R curl
Your system, once screen detaches, destroys the pts, and for some reason recreates it, if I understand correctly how udev 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 by ptmx, which is used to create pseudo-terminal master/slave pairs. pts/* is the slave of the respective PTM, 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 your ls 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 created pts/* 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. ;)
Best Answer
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/screenon my system, but sometimes/tmpis used). That exploit now has an path to getting root, which it might not otherwise.sudohas other advantages, if you can train yourself to use it for each command rather than doingsudo 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.