incompatible screen update
tmraz at redhat.com
Tue Feb 8 14:05:03 UTC 2011
On Tue, 2011-02-08 at 12:40 +0100, Lennart Poettering wrote:
> On Tue, 08.02.11 12:09, Miroslav Lichvar (mlichvar at redhat.com) wrote:
> > On Tue, Feb 08, 2011 at 08:42:52AM +0100, Lennart Poettering wrote:
> > > On Fri, 04.02.11 16:30, Miroslav Lichvar (mlichvar at redhat.com) wrote:
> > > > - $HOME/.screen is used as socket directory instead of
> > > > /var/run/screen
> > >
> > > $HOME is no place to place unix sockets. Unfortunately $HOME might be
> > > one weirdo file systems which do not support that. Expect bug reports
> > > about this soon.
> > Hm, screen wouldn't be the only one doing that, I see in my home
> > sockets belonging to rxvt-unicode and uim. Anyway, the directory can
> > be set by SCREENDIR environment variable.
> > Is this worse than allowing users to write in /var/run/screen? (bug #667252)
> Good question.
> Precisely for issues like this XDG_RUNTIME_DIR has recently been
> We carefully made sure to define the semantics of this dir to offer a
> safe place to put these sockets.
> While it might appear easy to simply make use of XDG_RUNTIME_DIR if set
> in screen, and have all problems go away on modern systems (i.e. >= F15),
> but unfortunately things aren't that easy: the lifetime of
> XDG_RUNTIME_DIR is strictly bound to the user being logged in. Since
> screen currently does not set up a PAM session it does not count as
> login right now and hence will not be able to use this dir when the user
> terminates all his real logins.
> That all said, I actually do believe that screen should invoke the PAM
> session setup code. Ideally, one of those days we enable automatic
> cleanup of all processes started from a session when a session
> ends. That would break screen unless it is fixed to set up its own
> session environment. So, sooner or later it would be really great to
> have screen fixed this way.
The problem is it would require making screen setuid root which I do not
think it is too good idea.
I think much more reasonable is to just accept the fact that it might be
very reasonable and desirable on some multiuser system to allow users
having background processes that can keep running even after the user
logs out and not to try to enforce rules such as no user process left
after logout blindly on all systems.
No matter how far down the wrong road you've gone, turn back.
More information about the devel