[systemd-devel] SystemD, Gnome permission problems

[Zbigniew Jędrzejewski-Szmek]

On Sun, Apr 12, 2015 at 07:19:07PM +0200, Lennart Poettering wrote:
> 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...

But /tmp is also used for shared state (between services, but also
between different applications run by the same user, different
sessions of the same user, etc.). Such files are not bound to any
process, or any session, and should not be. For example, when I download
stuff I often stick it in /tmp, so that it stays around if I need it, but
goes away without me taking any concious action after some time.
Gnome's thumbnails are a bit like this: they are not bound to the life
cycle of anything, we just want them to go away when they have not been
used for a while.

The application which creates thumbnails (or other similar caches)
*should* take care to not use to much space when creating things rapidly.
I assume that gnome does that already. But the application cannot really
implement good time based cleanup, especially that time based cleanup
is especially useful when the application is *not* running.

I'm aware of various short-comings of shared spaces and time-based
cleanup, but I don't think there's a better alternative for many cases.
Or more precisely: it works best for cooperative sharing, where various
entities involved are not malign, but not omniscient either.

[snip]
> 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...
Agreed, for 1-3, but not yet for 4.

> 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. 
Well, the whole discussion started with the fact that this cannot be
implemented as user code without being crippled.

> > 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.
sd-journald is a bit different: it is always around, and is important
for security, so normal "cooperative" cleanup rules don't apply to it.
OTOH, there are many user space caches (browser cache, image viewers'
thumbnails, downloads, format conversions) that could be cleaned up
periodically with an overall benefit to the health of the system.

I know that doing this properly and securely is hard... but I think
that current tools don't really cover this.

Zbyszek