[systemd-devel] systemd-tmpfiles for the user instance of systemd

[Lennart Poettering]

On Wed, 01.07.15 12:35, Daniel Tihelka (dtihelka at gmail.com) wrote:

> Hello,
> does anyone have an experience with the use of systemd-tmpfiles for the user 
> instance of systemd.

This is currently not nicely supported. And I am not sure it
should. Note that much of what tmpfiles supports is only necessary
for:

- aging (automatic time-based clean-up of files). Doesn't really apply
  to user sessions, since /tmp and /var/tmp are already cleaned up by
  the system instance of tmpfiles

- re-populating /etc and /var on state-less boots, possibly apply
  perms and stuff. Doesn't really apply to user sessions, since since
  time began user apps are used to recreate their stuff in $HOME on
  first start.

- help borked daemons or daemons that never have priviliges to create
  directories in /run that are owned by system users. Doesn't apply to
  user sessions, since in that case there can only be one user that
  owns all files.

- reserve certain guessable file names in otherwise shared namespace
  directories (i.e. /tmp/.X11* stuff) before the first user logs in,
  in order to avoid DoS attacks. Doesn't apply to user sessions, since
  there are no different privilege levels for those.

- write fields into sysfs. Doesn't apply to user sessions, since user
  sessions generally don't have access to sysfs.

Summing this up: all these cases don't really apply to user
sessions. Moreover, it's not really possible to implement aging from
unprivileged programs, since you cannot avoid bumping the atime of all
dirs when doing that, since noatime stuff is only available to root...

> * I have to specify the config file manually (i.e. %h/.config/tmpfiles.conf). 
> There is no attempt to search for e.g. ~/.config/tmpfiles.d/ or 
> /etc/tmpfiles.d/user/ directories when running in user mode. Is that
> correct?

Yes. And I have no intenation to change that, given the issues above.

> I just want to ask, since I do not want to make the stuff more complicated than 
> necessary. So I am all ears if if you know how to simplify/generalize the 
> configuration

I fear it will stay the manual process your described...

Lennart

-- 
Lennart Poettering, Red Hat