[systemd-devel] Best practice for prepopulating the CacheDirectory of dynamic users

[Lennart Poettering]

On Di, 27.02.18 14:37, Antoine Pietri (antoine.pietri1 at gmail.com) wrote:

> Hi!
> 
> To experiment with systemd dynamic users, I started working on a
> wrapper around a program that builds user packages (Archlinux makepkg)
> and that refuses to be launched as root (for very good reasons). The
> idea is that the wrapper just calls:
> 
> systemd-run --pipe \
>   -p DynamicUser=yes \
>   -p CacheDirectory=mywrapper \
>   -p WorkingDirectory=/var/cache/mywrapper/build/repo \
>   makepkg
> 
> However, to be able to run makepkg, its cache directory has to be
> pre-populated with a clone of the package to build. So, from my
> wrapper, I just did:

Does it have to be a writable copy? if not you could just do '-p
BindReadOnlyPaths=/path/to/my/source:/var/cache/mywrapper'

i.e. there's no need to actually use the CacheDirectory= logic if the
semantics aren't right for you.

That said, maybe we should add a concept of TemplateCacheDirectory= or
so, which would allow prepopulating the dir from some external
source. 

> - My current workaround is to shell-out to `systemd-run -p
> DynamicUser=yes ...` first to do a mkdir -p, then for a cp -R. This
> solution requires a lot of boilerplate from the Python wrapper and
> takes more time for no good reason, so I think it's not ideal.

This sounds OK to me tbh.

> - I believe another solution would be to modify /var/cache/private
> directly, but I'm not sure it's a good practice to do so because I
> don't know if this path is reliable or just an implementation detail.
> Plus, it requires a weird special case compared to when I don't run
> makepkg with systemd-run, as I have to insert something in the middle
> of the copy destination path.

I think it's safe to treat /var/cache/private/ as API. We document it
already at various places, and the semantics aren't overly
complex. Hence this approach is OK too, as long as you create the
relevant dirs if they are missing with the right perms.

Lennart

-- 
Lennart Poettering, Red Hat