dlutter@xxxxxxxxxx (David Lutterkort) writes: >> > 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. > > What I meant with vague is that the LSB doesn't have any detail on > the 100 - 499 range; throwing the uid's for packages and what system > admins do locally into one bucket is just a description of the status > quo. It means, that an LSB compliant package should not assign a static uid in the 100..499 range, and that an uid appearing there can be created only by 'useradd -r' (without '-u'). >> > 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... > > I agree that it would be hard to change for existing installations; you > yourself have noticed a need for change in that area and written > fedora-usermgmt. I am saying that with a clear policy we could improve > on what the LSB describes there. At the very least, it would clarify how > the desire for static uid's allocated above 100 can be reconciled with > the needs of FC/FE. Static uids above 100 are not possible for LSB compliant packages. >> > (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). > > /usr/share/doc/setup-2.5.44/uidgid on my FC4 system lists as the highest > uid (besides nfsnobody) gkrellmd as 101. gkrellmd is obviously a packaging bug. E.g. an installation sequence of 1. minimal install 2. something, which does 'useradd -r' 3. 'gkrellmd' installation will break at 3. because 2. created a user with uid 101. It also violates the LSB ;) > Which also means that something will have to be done for FC at some > not-too-distant point in the future. > >> It addresses this issue by: >> >> * being LSB compliant (dynamic allocation) in the default (unconfigured) >> case > > I think since the LSB describes something that's impractical in reality, > the LSB should be changed; Try it; but I have very little hope that LSB can be changed in this point because there are too much existing installations which use 100..499 for their own purposes. > but before we can have this discussion, we would need an example how > it should be changed witha more detailed allocation policy. My suggestion would be, to use 500..999 for static system uids. ;) Debian starts ordinary users already at 1000, now some other distros have to follow and some administrators have to re-uid their users ;) >> * 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 > > But it doesn't solve the fundamental problem that there is no assurance > that they map the uid's into a 'safe' uid range; The 'safe' range must be choosen by the administrator; the administrator can be sure that uids between 500 and 65533 (and perhaps the extended 32bit range) are available for his purposes. No package should assign a uid there. Which range within 500..65533 is safe for semi-static uids assigned by fedora-usermgmt depends on the local policy. > there is nothing to keep a package in FC to appear that will clash > with a uid from FE, for example. FC is going to become smaller in the future and there should be around 20 free uids below 100. So, FC can stay completely in the 0..99 range. Enrico
Attachment:
pgpiOCIKDRaXC.pgp
Description: PGP signature
-- fedora-extras-list mailing list fedora-extras-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-extras-list
