FPC isn't universally happy to be advocating for soft static allocation but we think we can reach an acceptable compromise to approve the draft. We need to add something about the criteria for choosing the soft static uids. Something like:

"""

Choosing the soft static uids and gids needs to be coordinated with other distributions. At the moment, some of the criteria might be:

1) See if upstream has uid and gid defaults
2) Look at Debian if they're allocating a uid and gid value there.
3) Look at FreeBSD/etc for the same.

If a cross-distro group existed to allocate these uids and gids, that would be even better but at the moment, such a group doesn't exist.

"""

I'll look into adding these to the draft this week. If you or anyone else has other criteria to add please mention it here.

FPC members also desired a link to report the bug against the setup package. Should be as simple as adding this: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=setup to the draft in an appropriate place.

Replying to [comment:1 toshio]:

We need to add something about the criteria for choosing the soft static uids. Something like:

"""

Choosing the soft static uids and gids needs to be coordinated with other distributions. At the moment, some of the criteria might be:

1) See if upstream has uid and gid defaults
2) Look at Debian if they're allocating a uid and gid value there.
3) Look at FreeBSD/etc for the same.

While I agree with the sentiment, I'd like to treat this as a separate issue that shouldn't block this draft:
1. To some extent, this is up to the "setup" maintainer and not a distribution-wide packaging concern (it affects the whole distribution, but only the "setup" maintainer needs to be aware of the concern).
2. This draft guideline was inspired by already having existing packages that use "hard static" allocation and can conflict with the policy-mandated "dynamic" allocation (see https://bugzilla.redhat.com/show_bug.cgi?id=924501 ); the draft will improve the situation even if the UID/GID allocation is Fedora-only.
3. Agreeing on cross-distribution UID/GID allocation is probably not possible: http://www.debian.org/doc/debian-policy/ch-opersys.html#s9.2.2 supports two ranges for static allocation: 0-99 (which is already full on Fedora) and 60000-64999 (which is not reserved in Fedora).

FPC members also desired a link to report the bug against the setup package. Should be as simple as adding this: https://bugzilla.redhat.com/enter_bug.cgi?product=Fedora&component=setup to the draft in an appropriate place.
Thanks, added.

Well, currently this draft is blocked. The changes proposed were suggested to unblock it (by gaining more votes and addressing more concerns.)

To respond to some of the specific comments:

1. My argument is that this is a distribution wide packaging concern for which the setup maintainer is currently the sole decision maker. The setup maintainer has often missed the point of the dynamic-uid vs static-uid distinction leading to adding uids to the static list that didn't need to be there. (this is a problem as we have a very limited pool of free static-uids [less than 100] to draw from.) Putting guidance that the setup maintainer needs to follow to make this decision is one avenue to fix that. A different avenue would be to put some Fedora decision making body in charge of it... in the meeting, tibbs made that suggestion and also noted that that would likely turn it into an FPC decision which (I believe, but I'm reading between the lines here) he wasn't thrilled about.

2. That looks like there's three bugs:

3. libvirt doesn't seem to have any reason to allocate a static uid. It should switch to the dynamic allocation in guidelines. This allows local administrators to pre-allocate the uid/gid if they need it for NFS on their site. It also allows things to work in the case the end user is encountering in that bug. It does not allow working cross-distribution but the guidelines you point out in #3 seem to indicate that is already the case.
4. the useradd and groupadd scripts need to allocate dynamic ids from the top down. Period.

5. the login.defs on the user's system is wrong. It's specifying overlapping ranges for the system static and "system dynamic" ranges. Perhaps this is also a shadow-utils bug where the hardcoded defaults should match Fedora policy.

6. that kinda restricts the reasons to have soft-static allocation at all. I believe that was also the conclusion of the original FPC when Ville explained the way the sysadmin can pre-allocate the uids and gids to make dynamic uids static site-wide.

I suppose we really need to go back to the basics of what static uids enable. It appears to me that is:
cross-site sharing of files via a network filesystem.
out-of-the-box sharing of files via a network filesystem in a homogenous RHEL and Fedora environment.
* pre-allocation of usernames so that software can't collide with usernames on a system (although it may cause someone to need to change their username for use on a certain system). (Note that soft-static does not achieve this goal)

heterogeneous sharing would fall under #3 above (ie: not possible).

I have a pretty dumb question. Why do the scriptlets need to differ in the static case? Static allocation just means setup defines the UID. If packages don't have to care, then downstream distros which really want to force static allocation can simply have their own setup package (which I expect they'd want anyway).

Replying to [comment:4 tibbs]:

I have a pretty dumb question. Why do the scriptlets need to differ in the static case? Static allocation just means setup defines the UID.

Yes, "setup" defines the UID, but not by adding it to /etc/passwd: compare https://git.fedorahosted.org/cgit/setup.git/tree/passwd and https://git.fedorahosted.org/cgit/setup.git/tree/uidgid . (AFAIK the reason for this is that rpm obviously can't just replace /etc/passwd on a running system, and doing some other kind of automated merging of user's passwd and our desired version is also risky.)

I suppose the setup package could have the useradd and groupadd scriptlets that the individual packages currently have (for static allocations). Gut reaction to that is "ick" but it does have some advantages:

• Packagers wouldn't mistakenly cargo cult static allocation from packages that actually have a good reason for doing that because the choice of static allocation would be in the setup package instead.
• sysadmins would have a plethora of examples of how to modify the setup package to create the proper uids and gids for their site.
• We really want static ids to be centralized for the distribution and doing the actual pre-allocation in setup will serve to centralize it.

Sometimes I really, really wish that someone would just solve the problem the right way and have /etc/passwd.d or something.

Replying to [comment:6 toshio]:

I suppose the setup package could have the useradd and groupadd scriptlets that the individual packages currently have (for static allocations).

That would work fine for me. Adding setup maintainer to the conversation.

(Note that upgrade concerns still make "strictly static" allocation (either in setup or in passwd.d) problematic.)

Replying to [comment:3 toshio]:

To respond to some of the specific comments:

1. My argument is that this is a distribution wide packaging concern for which the setup maintainer is currently the sole decision maker. The setup maintainer has often missed the point of the dynamic-uid vs static-uid distinction leading to adding uids to the static list that didn't need to be there. (this is a problem as we have a very limited pool of free static-uids [less than 100] to draw

Do you have some specific example for this "often missed the point" ? Actually, I denied static reservation for quite a few requests if it IMO doesn't make sense to have the system account statically reserved. For some reason, everyone started to ask for static id (ok, I know the reason - someone added check in one lint tool which recommended static allocation for every system account and people don't read the whole message). I think static id usage should be limited to accounts which handle sensitive data and/or are network facing (or communicating between virtual machines). These accounts may benefit from static allocation.
If you have an example, where it is clear that the static id was reserved and it was obvious it is not necessary, just tell me that and don't hide behind random tickets. I got no email indicating something wrong - and now you are saying "often missed the point".

from.) Putting guidance that the setup maintainer needs to follow to make this decision is one avenue to fix that. A different avenue would be to put some Fedora decision making body in charge of it... in the meeting, tibbs made that suggestion and also noted that that would likely turn it into an FPC decision which (I believe, but I'm reading between the lines here) he wasn't thrilled about.

When I reserve the uid/gid, I always take a look on the other distribution - if this id is not already used by some other third party software, not shipped in Fedora defaults. So pointing the guidelines to setup bugzilla should be just fine. You are right about the sole decision making - if you want to have all static id's approved by some committee, I'm fine with that - however in my opinion it just slows down the things for no obvious reason.

1. That looks like there's three bugs:
2. libvirt doesn't seem to have any reason to allocate a static uid. It should switch to the dynamic allocation in guidelines. This allows local administrators to pre-allocate the uid/gid if they need it for NFS on their site. It also allows things to work in the case the end user is encountering in that bug. It does not allow working cross-distribution but the guidelines you point out in #3 seem to indicate that is already the case.

Why do you think so? Virtualization is one of the places where static ID makes sense as well. I don't see much difference in communication between virtual machines and over network.

1. the useradd and groupadd scripts need to allocate dynamic ids from the top down. Period.

This is AFAIK already a way how useradd/groupadd works for dynamic allocation since F14?. I had a discussion with Peter Vrabec about it long time ago, as it was clear that doing from lowest numbers is only making things wrong.

I suppose we really need to go back to the basics of what static uids enable. It appears to me that is:
cross-site sharing of files via a network filesystem.
out-of-the-box sharing of files via a network filesystem in a homogenous RHEL and Fedora environment.
* pre-allocation of usernames so that software can't collide with usernames on a system (although it may cause someone to need to change their username for use on a certain system). (Note that soft-static does not achieve this goal)

Please add cloud environment and virtualization as other usecases for static uids.

Replying to [comment:6 toshio]:

I suppose the setup package could have the useradd and groupadd scriptlets that the individual packages currently have (for static allocations). Gut reaction to that is "ick" but it does have some advantages:

• Packagers wouldn't mistakenly cargo cult static allocation from packages that actually have a good reason for doing that because the choice of static allocation would be in the setup package instead.
• sysadmins would have a plethora of examples of how to modify the setup package to create the proper uids and gids for their site.
• We really want static ids to be centralized for the distribution and doing the actual pre-allocation in setup will serve to centralize it.

Because of the dependencies (bash and shadow-utils are after the setup and you don't want to play the dependency games there) it is not possible to have them in simple post/postun/pretrans scriptlets. Triggers might work, but triggers should be the last choice. I may add all the statically reserved id's into the default /etc/passwd and /etc/group file, however - this will make the default user set quite huge - many of these system accounts will never be used on vast majority of the systems. In addition - /etc/passwd and /etc/shadow creating all accounts doesn't solve the issue with updates - you can't play games with existing files, so new system accounts will still need handling in post scriptlets of the packages using them.

I do plan to do at least some setup-utilities - to check the system and warn the users if some system account is used unlike with uidgid reservation - as many admins are not aware of this file.

btw, for those who might not be subscribed to the packaging list -- discussion was started there about this draft http://lists.fedoraproject.org/pipermail/packaging/2013-April/009029.html

So far, I've seen a comment by Tom Lane that LDAP is a bad idea for system users which I think should be merged into the draft in some way.

Replying to [comment:10 ovasik]:

Because of the dependencies (bash and shadow-utils are after the setup and you don't want to play the dependency games there) it is not possible to have them in simple post/postun/pretrans scriptlets. Triggers might work, but triggers should be the last choice.

Yes, late last night as I was trying to recall what the FPC had discussed in approving the original guidelines. Came to the same conclusion that triggers would be the only way to enable this but that we'd rather avoid having to go that route.

In addition - /etc/passwd and /etc/shadow creating all accounts doesn't solve the issue with updates

Yep, mitr said the same in comment5 which lead to thinking about whether scriptlets would work. I think this line of thought (adding all system accounts via setup package) is showing itself to be too problematic.

As a first note: by the guidelines there are not supposed to be any new static ids allocated. This was put into place way back when we were running short on the 100 block of ids (I think in 2006). However, the setup maintainer disregarded that and instead of coming up with new guidelines that would address the issue of whether static ids were needed and if so how to allocate them they simply allocated new ids above the 100 limit.

I can understand how you might follow that precedent but doing so has always been wrong.

I think static id usage should be limited to accounts which handle sensitive data and/or are network facing (or communicating between virtual machines). These accounts may benefit from static allocation.

These criteria are wrong. The core of static ids and gids is about sharing of data that cannot use symbolic names for their ownership. This comes into play with networked filesystems because they record the user and group information as uid and gid for each file. Then the files are shared with other computers. If sharing is done via symbolic information (username and groupname) or the data is not being shared between computers then there is no need for a static id

Now it could be that some or even many network facing services need to share uid and gid information and it could also be that some or many security sensitive services need to share uid and gid information. But if they don't have that component there is no need for static ids.

This is AFAIK already a way how useradd/groupadd works for dynamic allocation since F14?. I had a discussion with Peter Vrabec about it long time ago, as it was clear that doing from lowest numbers is only making things wrong.

If you check out mitr's linked bug report, you'll see the situation in which this is currently broken.

Please add cloud environment and virtualization as other usecases for static uids.

As noted above, I think that you're being overbroad here. There can certainly be cloud and virtualization services where static uids would be helpful but there can equally be cloud services where it doesn't matter. An http-based frontend to managing cloud services, for instance, could likely do just fine with dynamic uids.

Alternate draft promised at the last meeting: https://fedoraproject.org/wiki/User:Toshio/UsersAndGroups

I've included both the original text and Mitr's draft text in the history but this is a large reorganization of the page so the diff is probably not very helpful.

@mitr: There's one specific question in the page for you about the soft static recipe.

Not a lot of substance has changed. Things that I remember:
Reorganized to integrate the large section of miscellaneous notes more fully into the rest of the page. Hopefully that will make for easier reading.
Inline LDAP comments removed and an admonition-box created mentioning the caveats of using LDAP for system accounts. I didn't mention SSSD specifically but I could if that's deemed appropriate.
FPC made the gatekeepers for allocating uid and gid. Not sure of some of the implementation details of this. We could: have commit to the Fedora setup package, have commit to the setup package upstream, or pull the uidgid file into a Packaging: wiki page.
Changed the section (two sentences) talking about criteria for soft static ids. It now reads: " Soft static allocation is only appropriate for packages where the UID or GID values are shared between computers. For instance, if the package creates files with the assigned UID or GID that are likely to be shared over NFS." This is stricter than before and is definitely different than ovasik's criteria. FPC, please correct me if this is the wrong direction to take the criteria in.

Replying to [comment:14 toshio]:

Alternate draft promised at the last meeting: https://fedoraproject.org/wiki/User:Toshio/UsersAndGroups

This adds the scriptlet guidelines, so I'm happy with it. I don't have any opinion on who/how should be doing the ID allocation.

@mitr: There's one specific question in the page for you about the soft static recipe.
(groupadd -f) is the equivalent of the "getent passwd ALLOCATED_UID" conditional. useradd doesn't have the equivalent of the -f flag, so the conditional needs to be spelled out explicitly.

abadger1999's draft approved (+1:6, 0:0, -1:0)

@ovasik: in regards to implementing this, how would you like to proceed? Should we (FPC) make changes to the Fedora setup package whenever this changes? Or would you rather give us commit rights to the upstream setup hosted project? Or rather that we make the canonical list be in the wiki and the uidgid file just pulls from there?

At the moment, I require bugzilla to track the request. If I get new one, I'll redirect them to you - and filing ticket to FPC. I expect bugzillas will still be coming even with the guideline change - not a big deal as I can redirect them to you.

I would prefer if you just add me to the ticket and I can handle it based on the FPC decision. Wiki behind write ACLs for FPC might work as well, I may check the latest version in the setup updates as I do with IANA port and protocols reservations. Definitely should be behind some ACLs to prevent vandalism. As the common practice in Fedora is at the moment means tarball rebases to the git versions from fedorahosted, I may grant FPC guys (or one of you) the commit rights to setup upstream on fedorahosted.

I don't want the option of directly editing Fedora's distgit by FPC when some new id is approved. I don't expect high traffic, in 5 years I got ~60 requests and I found 46 of them valid. With your even stricter criteria, it may be just a few new ids per year.

Written up.

Announcement text:

The Guidelines for creating users and groups in packages and assigning static UIDs and GIDs has been changed. For those making use of dynamic UIDs and GIDs in their packages nothing should change. For those with new packages wanting to use static UIDs and GIDs, the important note is that you should now ask for the FPC to assign those for your use with information about why the UIDs and GIDs need to be static. For those using static UIDs and GIDs this is a large update that you should definitely read over as they provide a recipe that allows sysadmins to override our UID and GID choices if needed at their site. It should be considered a bug in your package if you continue to use the older method of statically assigning UIDs and GIDs since that will prevent admins from setting their own UIDs and GIDs based on the methods mentioned in the guidelines.

The updated Guidelines are at: https://fedoraproject.org/wiki/Packaging:UsersAndGroups

This is another ancient one that was written up but never announced. Probably not worth announcing it now, nearly two years later, so I'm just going to close this.