To be sure, you created a bird group put the users you want accesses into it and then the service is not running with this group?

I didn't create the group. Previous versions of the package created the user/group, so do other distributions and even upstream does it that way in their packages (https://build.opensuse.org/package/view_file/home:CZ-NIC:bird-latest/bird/bird.spec?expand=1). I think Arch Linux should ship a sysusers file so the package creates a user+group. With the dynamic ids it's also not possible to chown config files to the bird user.

You need to create the group (or user) first if you want to play with users/group ids (chown, groupadd, etc).
Static (and well-known) ids are required when the package ship files owned by an uid > 0.

The permission management should be equivalent as soon you have created static users/group.
So, I understand your issue is more about the user/group not created when the package is installed.
Here, this is done on purpose, to add some extra security and reduce the number of useless static users.

But is this worth it? every other bird package I found provides a static user, just Arch Linux goes a different path and that probably leads to confusion for some people. Also I think it's common practice that files containing secrets should be owned and only readable by the user that requires it. That's not possible out of the box on Arch Linux. I still think we should ship a sysusers file.

DynamicUser=true actually forces the config to be insecure by default, which doesn't seem like a good strategy.

IMO DynamicUser=true is only usable when (at minimum) all of the following conditions are met:
a) The application has no sensitive configuration data.
b) The application has no unix socket for external communication.
c) The application has no persistent state.

Bird fails conditions (a) and (b). I suppose technically (c) is the only hard blocker to DynamicUser, but if users of the package have to create a system user/group for sensible and secure operation anyway, what's benefit of not shipping it for them as standard, like all other distros do?

What's the verdict here? It seems relatively easy to fix this package to have sensible defaults by provisioning a user during install, and deploying the config with secure default permissions. This also allows use of the unix socket out of the box.

I cannot see a good argument for forcing users to do this work post-install, simply to avoid creating a sysuser - every user of this package will want to configure a static user for it (whether they know it or not), and this is the standard deployment strategy for all other distros.

@pdf: Not arguing for or against this change, but your declaration about `DynamicUser` with persistent state is not correct, this is specifically what `StateDirectory=foobar` is for in conjunction with `DynamicUser=true`. It allows a writable persistent location while still protecting it from potential uid reuse due to `DynamicUser=true` (Same for CacheDirectory and LogsDirectory).

If its as simple as a single config file that needs ownership, this does not strictly require a static id when systemd tmpfiles feature is used. One example is umurmur:
https://github.com/archlinux/svntogit-community/blob/packages/umurmur/trunk/umurmur.tmpfiles#L1
https://github.com/archlinux/svntogit-community/blob/packages/umurmur/trunk/umurmur.sysusers

Appreciate the clarification on StateDirectory, unfortunately that's the only condition from that list that this package doesn't require.

We are in a basic situation, a daemon that runs with a dedicated user, its config file not writable by the running process and owned by root in /etc. A socket that by default allows only the root user to interact with it. The default config file has no secret and permission is set accordingly.

Well, the config has sensible defaults and DynamicUser= does not force the config to be insecure.

The common use case for bird is to exchange routes with network peers, which do not require a defined uid/gid, a persistent static directory or even a secret in config file.
So, on the contrary, making the daemon run by default with no persistent files/static uid/gid, enforced by systemd seems to me rather healthy.

If we imagine more complicated use cases like:
1) You require a secret in your bird config.
=> You could easily change the permission on /etc/bird.conf.

2) You want regular users to be able to talk to the daemon (add routes, restart, etc)
=> You could define a static gid and start assigning users to group.

I don't have a dogmatic opinion on the subject, I have other packages that work that way for different reasons.

I just want to point out that it's quite common to have passwords in the bird configuration file(s). That's best practice for protocols like BGP. And it's common for monitoring tools like bird_exporter to connect to the provided socket. I still stand with my previous statement from above:

> But is this worth it? every other bird package I found provides a static user, just Arch Linux goes a different path and that probably leads to confusion for some people. Also I think it's common practice that files containing secrets should be owned and only readable by the user that requires it. That's not possible out of the box on Arch Linux. I still think we should ship a sysusers file.

I don't see any positive sideeffect of DynamicUser= and just the fact that it makes system administration way way easier if the Arch Linux box has the same defaults as every other distribution would be a reason for me to add the sysusers file. That's also how I handle it with my own packages in community.

> Well, the config has sensible defaults and DynamicUser= does not force the config to be insecure.

DynamicUser forces the config to be insecure in that must be world-readable.

> The common use case for bird is to exchange routes with network peers, which do not require a defined uid/gid, a persistent static directory or even a secret in config file.

I guess this is the rationale for the package being configured the way it is, but this statement is false. Secrets are typically required in the bird config - this is not a "complicated use case", it's the common use case.

> You could define a static gid and start assigning users to group.

I've not heard what the rationale is for forcing users to deal with this, instead of providing sensible defaults in the package.

I believe that the package should add a dedicated uid/gid, and that by default the config file should be mode 0640, with owner root:bird.

Just in case it got lost in the last few messages, its extremely easy and hassle free with a combination of sysusers+tmpfiles

One example is umurmur:
https://github.com/archlinux/svntogit-community/blob/packages/umurmur/trunk/umurmur.tmpfiles#L1
https://github.com/archlinux/svntogit-community/blob/packages/umurmur/trunk/umurmur.sysusers