On Sun, 12.04.15 14:11, Zbigniew Jędrzejewski-Szmek (zbys...@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 _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
