[gentoo-dev] [RFC] systemd's DynamicUser= in .service files

[gentoo-dev] [RFC] systemd's DynamicUser= in .service files

[Georgy Yakovlev]

[-- Attachment #1: Type: text/plain, Size: 1286 bytes --]

Hi,

As of version 2.3.2 systemd includes support for creating a user to run a 
service as, and extended support since 2.3.5. [1]

Currently we have stable 233-r6 and 236-r5 on amd64.

Since we have to support both openrc and systemd in gentoo, and will have 
create a service user for running under openrc anyways, does it make any sense 
to provide service files with DynamicUser=yes ?

If a statically allocated user/group already exists, and unit file contains 
relevant User=/Group=,  the configured user  is used and no dynamic user/group 
is allocated. [2]

According to 'grep'  there are 2 packages currently in the tree:

net-p2p/cpuminer-opt/files/cpuminer-opt.service
8:DynamicUser=true

net-p2p/xmr-stak/files/xmr-stak.service
13:DynamicUser=true

Both  do not provide OpenRC files, so it makes sense.

Maybe other packages also use that with upstream provided service files, I 
haven't checked.

What I'm asking for is your opinion if it's something that should be used in 
gentoo or should I try to avoid it if possible, especially if a static user is 
alredy present in the system.

Thanks!

[1]: http://0pointer.net/blog/dynamic-users-with-systemd.html
[2]: https://www.freedesktop.org/software/systemd/man/
systemd.exec.html#DynamicUser=

---
Regards, 
Georgy Yakovlev.

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] [RFC] systemd's DynamicUser= in .service files

[Rich Freeman]

On Sun, Feb 11, 2018 at 6:46 PM, Georgy Yakovlev <ya@sysdump.net> wrote:
>
> What I'm asking for is your opinion if it's something that should be used in
> gentoo or should I try to avoid it if possible, especially if a static user is
> alredy present in the system.
>

If the systemd behavior is to just fall back to the static user if it
exists, I don't see the point in disabling it, since at worst it is a
noop, and at best it could be useful on stateless systems/etc.  I
suspect that unit files that enable this came from upstream sources,
and it seems like a bad idea to go patching an upstream unit file just
to disable something that doesn't cause an issue.

-- 
Rich