[systemd-devel] SystemD, Gnome permission problems

[Lennart Poettering]

On Mon, 13.04.15 02:37, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) wrote:

> > 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.). 

Not really. Shared state is what /run is for really.

Note that we kinda encourage all services to set PrivateTmp=, and
consider daemons which need a shared /tmp to be a thing of the past,
that should better be fixed.

If you want to pass files in /tmp around, that's fine, but it's almost
certainly something where aging is the wrong answer. I much better
lifecycle management for files in /tmp could be something like a
O_TMPFILE that however keeps the filenames in the directory visible as
long as the file is opened. i.e. a scheme where a file is deleted the
moment the last fd is closed for it, but until then is a normal file
with a filename and everything, where the filename can be used to
create additional fds, and all.

> 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.

I very much disagree. Especially the thumbnailing thing is something
where the clean-up should be primarily bound to size on disk
constraints, and tmpfiles really cannot help with size on disk...

Doing this based on aging via tmpfiles would be a hack, that people
might resort to only because proper size-based cleanup is missing.

> 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 am not sure what benefit it would be to have time-based clean-up for
this. Enforcing a disk space limit, plus replacement in LRU style
would make sense, but there's little point in deleting old entries
really.

And even if we say that time-based clean-up would be useful: the
*primary* logic should *still* be about disk space limits, nothing
else. And if you implement that in the thumbnailer, then you should
also implement the time-based cleanups.

Let's not forget that tmpfiles is actually a really dumb thing. It
looks at the file dates only, and has no idea at all about how files
fit together. It will remove individual files with completely
disregard of how they fit in the big picture, and related to other
files. Such a scheme is OK for cases like temporary files in /tmp,
since every file there probably can be considered independently of all
others. But for things like the thumbnailing it might actually not be
true at all...

> > 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.

Which kinda indicates that we probably shouldn't be doing that all ;-)

Lennart

-- 
Lennart Poettering, Red Hat