Thoughts about user and group handling in packages
This is a collection of notes posted by various people in the user and group handling packaging draft, kept around for future reference. This is not a policy nor should the notes be interpreted as guidelines!
Here's a collection of past notes made regarding the issue. Some are taken into account in the above, some are not, some are more useful than others. These are not part of the actual draft, at least yet. Approach with care.
- Static, pseudo-static or dynamic uid mappings, uid ranges if non-dynamic? (TBD: is this within the scope of this doc?)
- Document users in use in the whole distro somewhere (no matter how uid mapping is done)?
- General stuff, eg. shell, comment, no password, where to put home dirs, whether or when to create private groups
1. Before submitting the package for review, add the user to PackageUserRegistry, set the 'Under Review' field and fill in the other ones. Use a consecutive number for the 'hint' field. Rationale::
- some administrators want predictable uids on their systems; registering users before the corresponding package hits the repository and gets installed on the system, will give the administrators a chance to do the precautions to deal with the new user
- TODO: require that a certain time (7-14 days) has to pass until package is published?
1. Make sure that package is not part of a Base installation; there is no simple way for administrators to install a local user policy during the initial rpm transaction
- TODO: enhance Fedora in a way that
/etc/passwdis brought in by a virtual, easy to replace package
%global username <username> %global hint <hint> %global homedir %_var/lib/%username Requires(pre): /usr/sbin/useradd #/usr/sbin/groupadd Requires(postun): /usr/sbin/userdel #/usr/sbin/groupdel Provides: user(%username) = %hint Provides: group(%username) = %hint %pre id '%username' || /usr/sbin/useradd -r -d %homedir -s /sbin/nologin -c '...' %username || : %postun test "$1" = 0 || /usr/sbin/userdel %usernameto your spec file.
%globalis easier to use than
%defineand often this, what packagers really want
homedir %_var/lib/%username... most common location for a homedir
Requires(...):... should be clear
Provides: user(%username) = %hint... allows to query the repository which package creates which user; it is possible to use it in constructs like
Requires(pre): user(foobar) Requires(pre): group(foobar)
%files %attr(-,foobar,foobar) %_var/lib/foobar/data</pre>
- <code>id '%username' || ... ... precheck whether user already exists; this avoids the expected "user already exists" message on package upgrades/reinstallations
useradd -r... must be set to enable dynamic uid allocation and to mark it as a system account (which has e.g. no default expiration time)
useradd ... -s /sbin/nologin... most common shell for service users
- update PackageUserRegistry:
- replace 'uid/gid' with 'hint', 'idx' or whatever
- add 'Under Review' field
- add fields where other useradd information (or the whole
useraddcommandline) can/must be entered
- provide a way which exports the table e.g. in a CSV format
- sample registry could look like
|user-/groupname||Purpose||Packages||Under Review||command line|
|123||foo||The user who is running the 'foo' service||foo||Y (#246788)||-r -d /var/lib/foo -s /sbin/nologin -c 'Foo User'|
- add explicit '/usr/sbin/groupadd' stuff?
- is the
useradd ... || :really needed or would it be better to fail? Distinguish between the different exit values there?
- do the
userdelstuff? On one side, after an rpm install-uninstall sequence the system should be in the state as before. On the other one, there might exist files with private information owned by the old uid. When creating a new user he might get the old uid and read these information
%hintstuff really useful?