Community Packages

Please read this before reporting a bug:
http://wiki.archlinux.org/index.php/Reporting_Bug_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 2
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?

Loading...