[systemd-devel] SystemD, Gnome permission problems

[Lennart Poettering]

On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> I'm wondering if we should provide better per-user tmpfiles support.
> For example, if we allowed a set of "user" tmpfiles, which would
> be executed by the system instance, but would be considered relative to
> the home directory and XDG_RUNTIME_DIR (~ or %h to refer to the home directory,
> %t to XDG_RUNTIME_DIR, ...). We would execute that for every user.

I'd be careful with this. I mean, I generally think that the fact that
we need tmpfiles is not a strength, but really just a work-around
for limitations of Linux. The tool covers four major usecases:

1. set up the work environment for daemons which are too dumb to do
   this on their own

2. set up the work environment for daemins that never run privileged,
   and hence cannot set up their work environment

3. Reserve a few file/directory names, to avoid namespace clashes in
   world-writable directories. Most notably that's the X11 stuff in
   /tmp.

4. Do "aging/clean-up" of /tmp.

Now, of these the first item is a work-around for broken daemons, and
this should really be better fixed in the daemons themselves. A daemon
that does not require tmpfiles is a good daemon. The third item is a
work-around against really broken semantics of X11, that cannot really
be fixed without breaking compat... But this issue is certainly not
something new code will fall for (hopefully)... The fourth item is a
work-around for broken semantics of UNIX, where files cannot be bound
to proper lifecycles of other objects, such as processes... "Aging"
these dirs is actually really nasty, since its cleanups are in no way
bound to the actual algorithms creating the files: code that generates
a lot of files in a short time, will be cleaned up only much later,
when the tmpfiles job happens to runs again...

Only the second item is really a genuinely useful thing I believe, all
the others are work-arounds around otherwise crappy designed
code... And for the second item things like RuntimeDirectory= are
probably a much better option, since it has properly synced up
lifecycle guarantees...

Now, if we look at all of this and how it would apply to the
unprivileged user session, then I don't think issue #1 applies, simply
because desktop software traditionally always was capable of setting
up its own work environment, simply because boot scripts and RPM
scripts couldn't cover new, unseen logins. Issue #2 doesn't apply
because everything is unprivileged. Issue #3 doesn't apply, either,
since this is about protecting system code against unprivileged code,
but not unpriviliged code against itself. Finally, the solution for #4
that we apply on the system already covers this for the session too.

The fact that tmpfiles exists is sad, and we shouldn't add this to the
session, so that the same sad practices we see on system daemons are
also adopted by desktop software...

Moreover, I'd always be careful with adding privileged code that
operates on unprivileged files, based on unprivileged configuration. I
mean, the cleaning of /tmp has always been a source of security
issues, it's really hard not to do things wrong when operating as
privileged code on unprivileged files (think symlink attacks!), but
it's a whole new dimension of risk, if we not only operate on those
unprivileged files, but also use unprivileged user-supplied configuration...

Hence, if this is done at all, it really should be the user's code
that runs this, not the system code. 

> gnome could possibly replace its custom thumbnails cleaner with a few
> lines of tmpfiles config. There would be two advantages: creation time
> cleanup could be replaced with access time cleanup, cleanup wouldn't
> be dependent on the session running.

I think it would be a good idea if the thumbnailing code of GNOME
would clean up the thumbnails stuff properly on its own, and that from
the same code that writes the thumbnails, in a similar way as journald
keeps track of its journal directory. That's the only way to make this
robust: don't clean it up triggered on time, but closely bound to the
algorithm that might fill it up.

I hope this makes sense?

Lennart

-- 
Lennart Poettering, Red Hat