dlutter@xxxxxxxxxx (David Lutterkort) writes: >> > UID For use by/managed by >> > 0-199 Fedora Core, FC steering committee >> > 200-299 reserved for future allocation >> > 300-399 Fedora Extras, FeSCo >> > 400-499 reserved for future allocation >> >> not possible; accordingly FHS, these ranges are available for free use >> and must not be assigned statically. > > Actually, that's a very loose paraphrasing of what the LSB (not FHS) > says[1]: > > The system User IDs from 0 to 99 should be statically allocated > by the system, and shall not be created by applications. > > The system User IDs from 100 to 499 should be reserved for > dynamic allocation by system administrators and post install > scripts using useradd. > > This is pretty vague, as far as standards go, I think it is pretty clear... an LSB compliant package should not assign a static uid in the 100..499 range. Only 0..99 is available for static uids. > and clearly, having only 100 user id's for statically allocated users > is not practical agreed. But this rule is originated >10 years ago when people thought there would be no need for more than 100 system users. It is far too late to change it now... > (FC itself already uses more than 100 system users) Are you really sure? At least FC4 should be below this mark (around 80 users, afair). >> They might be already in use in existing systems, and a static >> assignment in future FE packages WILL create conflicts. > > Absolutely; though I don't see how fedora-usermgmt addresses that > issue. It addresses this issue by: * being LSB compliant (dynamic allocation) in the default (unconfigured) case * allowing administrators who do not want the mess of inconsistent uids to assign predictable uids which are identically at each rpm run and on every system > This seems like an argument for always allocating uid's dynamically > for FE system accounts, and changing the packaging guidelines so that > packages will not remove users Not removing uids violates my idea of packaging (package removal should restore the system to the state before package installation) > (which fixes the security risk from reused uid's) It would also erase > the one big benefit of statically allocated uid's: easy correpsondance > of users across machines in a network for things like NFS filesystems. I do not see how a do-not-erase-users rule would guarantee identical uids on different machines. >> The fact is, that you will not find a free range for new static uid. The >> only possible range for static uids is 0-99 which is reserved for Core >> already. > > I think this is mainly because there has never been a clear guideline > on what to do. When something is clear, then, that 0..99 is reserved for Fedora Core. >> > For Fedora Extras, user id's would be tracked as they are right now >> > at http://fedoraproject.org/wiki/Packaging/UserRegistry (with all >> > uid/gid's bumped up by 300) and new uid's/gid's would be allocated >> > during package review from the FE range 300-399. > > It seems that that page > http://fedoraproject.org/wiki/Packaging/UserCreation is only a > recommendation, not a requirement for package review. Could you change > the page to clearly state that it's not a packaging requirement? ok, should be done > I think it's pretty confusing as it is right now. afaik, this page was never referred from some packaging guideline. >> I am in doubt that we will stay below 100 users... > > Absolutely. But for the time being, it's enough; once we approach the > 100 uid's we would have to either allocate more uid's or think of > something else. LSB people had probably the same idea when they created the rules about the uid ranges years ago... Enrico
Attachment:
pgpVfqnqNT8xC.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
