Community Packages

Please read this before reporting a bug:
https://wiki.archlinux.org/title/Bug_reporting_guidelines

Do NOT report bugs when a package is just outdated, or it is in the AUR. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!
Tasklist

FS#71902 - bird 2.0.8-2 uses DynamicUser=true which makes permission management hard

Attached to Project: Community Packages
Opened by Tim (bastelfreak) - Monday, 23 August 2021, 08:29 GMT
Last edited by Andreas Radke (AndyRTR) - Tuesday, 31 August 2021, 20:58 GMT
Task Type Bug Report
Category Packages
Status Assigned
Assigned To Sébastien Luttringer (seblu)
Architecture x86_64
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 3
Private No

Details

Description:

since bird 2.0.8-2 our unit file DynamicUser=true. This makes permission management a bit tricky. On other distributions it's common that a real user is created, it owns the configuration files and also the unix socket. Other services that need to access the socket, for example to extract metrics like https://github.com/czerwonk/bird_exporter/releases does it, run as a separate user and are added to the bird group. This won't work with DynamicUser=true. Are there any huge benefits I miss by using DynamicUser=true?

Additional info:
* package version(s) bird 2.0.8-2 and newer
* config and/or log files etc.
* link to upstream bug report, if any

Steps to reproduce:
* install bird
* try to add another user to the nonexistent bird group


I'm happy to provide a sysusers file or to comaintain/adopt the package, but then it would need to be moved to community.

Cheers, Tim
This task depends upon

Comment by Sébastien Luttringer (seblu) - Monday, 23 August 2021, 17:31 GMT
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?
Comment by Tim (bastelfreak) - Monday, 23 August 2021, 18:02 GMT
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.
Comment by Sébastien Luttringer (seblu) - Monday, 23 August 2021, 18:36 GMT
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.
Comment by Tim (bastelfreak) - Thursday, 02 September 2021, 13:38 GMT
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.
Comment by Peter Fern (pdf) - Sunday, 10 October 2021, 21:26 GMT
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?
Comment by Peter Fern (pdf) - Tuesday, 25 January 2022, 02:20 GMT
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.
Comment by Levente Polyak (anthraxx) - Tuesday, 25 January 2022, 10:13 GMT
@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
Comment by Peter Fern (pdf) - Tuesday, 25 January 2022, 10:29 GMT
Appreciate the clarification on StateDirectory, unfortunately that's the only condition from that list that this package doesn't require.
Comment by Sébastien Luttringer (seblu) - Tuesday, 25 January 2022, 12:53 GMT
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.
Comment by Tim (bastelfreak) - Tuesday, 25 January 2022, 12:59 GMT
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.
Comment by Peter Fern (pdf) - Tuesday, 25 January 2022, 14:16 GMT
> 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.
Comment by Levente Polyak (anthraxx) - Tuesday, 25 January 2022, 14:24 GMT
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

Loading...