On Mo, 06.01.20 20:44, Claes H (claesatw...@gmail.com) wrote: > On Mon, Jan 6, 2020 at 1:40 PM Lennart Poettering > <lenn...@poettering.net> wrote: > > > > If possible use DynamicUser=1, i.e. have a short-lived user that only > > exists while your service is running. > > > > For some usecases that doesn#t work though. There's a TODO list item, > > to add AllocateUser= as new switch to create a user persistently on > > first start, as an alternative for such cases. Nobody worked on that > > yet though. And of course, it's much less sexy since for such users > > the portable services would suddenly leave traces on the system, in a > > way that is never cleaned up... > > > > I will see if I can get DynamicUser to work. If I understand that > correctly, it is mainly useful when the service is truly self > contained / having its own sandbox.
Yes. If the service is supposed to for example write files visible to other services that DynamicUser=1 doesn't work really. > I want the service and myself to be able to read and write to the > files in its configuration / runtime directory. That is why I have > Bind-mounted it into the service's file system. Need to read up on the > state directory concept for DynamicUser. But it seems complex. > > The AllocateUser concept seems very useful for when the usecase is to > bundle up a fast moving application with all its dependencies. I would > not mind so much about the traces that can be left. If it is > implemented, probably should include something like AllocateGroup > too. Would be delighted to review a patch for that ;-) Lennart -- Lennart Poettering, Berlin _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
