Hello, at the moment static system level uid/gid's are handled by setup package and /usr/share/doc/setup-*/uidgid file. There is threshold of system uid/gid's - it's uid/gid 100. Another way to reserve "static" uid/gid reservation is http://fedoraproject.org/wiki/PackageUserRegistry ... usable only for Fedora and only semi-static (as base id could be easily changed). As we are running out of the free uid/gid's in uidgid reservation file (no free gid's in fact at the moment), it has to be solved somehow... there are quite often requests for uidgid reservations as it increases security in many cases...
What's the best way to handle that situation? One possibility is to increase the threshold of system level id's (to 200? 300?), another is to check current reservation and clean long-term unused reservations (I doubt there are many such cases, so it's only temporary solution). Other could be sharing groups (as static uid's are still available), but that's not always good solution.
Any other idea or some prefered solution?
Greetings, Ondřej Vašík
2009/4/28 Ondřej Vašík ovasik@redhat.com:
Hello, at the moment static system level uid/gid's are handled by setup package and /usr/share/doc/setup-*/uidgid file. There is threshold of system uid/gid's - it's uid/gid 100. Another way to reserve "static" uid/gid reservation is http://fedoraproject.org/wiki/PackageUserRegistry ... usable only for Fedora and only semi-static (as base id could be easily changed). As we are running out of the free uid/gid's in uidgid reservation file (no free gid's in fact at the moment), it has to be solved somehow... there are quite often requests for uidgid reservations as it increases security in many cases...
What's the best way to handle that situation? One possibility is to increase the threshold of system level id's (to 200? 300?), another is to check current reservation and clean long-term unused reservations (I doubt there are many such cases, so it's only temporary solution). Other could be sharing groups (as static uid's are still available), but that's not always good solution.
One long term solution is to replace (or rather back up) the uid/gid integer system with uuids. This also helps with other problems like Windows interop.
Here's a blog post about a change Solaris made in this respect: http://blogs.sun.com/nico/entry/dealing_with_windows_sids_in Mailing list thread in NFSv4 context: http://www.nfsv4.org/nfsv4-wg-archive-dec-96-jan-03/1440.html
I'm sure there's other stuff out there.
Another thing to consider would be relying on SELinux domains for new daemons, just give them e.g the "daemon" uid.
2009/4/28 Ondřej Vašík ovasik@redhat.com:
Any other idea or some prefered solution?
Another idea (not exclusive with the uuid approach) is to have a global system flag somewhere in /etc which lets admins make the tradeoff between:
* Compatibility with previous releases, large uid space for their own use, many system daemons will get dynamic uids installed * Large system uid space, incompatible assignment with earlier releases
Basically if you pick the first option, then when some new daemon not in the static list is installed it gets "adduser" dynamically (and the files have to be chowned, needs RPM level work most likely to not break -V etc.).
This approach requires a "flag day" where we bump the system uid space of course.
Oh regardless of anything else, one thing SSSD or whatever really should add is something to distinguish between a uid for some system service and a uid intended for an actual human (the heuristic of having a $HOME be in /home is kinda ugly).
Ondřej Vašík (ovasik@redhat.com) said:
What's the best way to handle that situation? One possibility is to increase the threshold of system level id's (to 200? 300?), another is to check current reservation and clean long-term unused reservations (I doubt there are many such cases, so it's only temporary solution). Other could be sharing groups (as static uid's are still available), but that's not always good solution.
Any other idea or some prefered solution?
Simplest way is to bump the lowest number that's used for system IDs; that may run into some collisions on older systems, though.
Bill
| Date: Wed, 29 Apr 2009 11:30:48 -0400 | From: Bill Nottingham notting@redhat.com
| Ondřej Vašík (ovasik@redhat.com) said: | > What's the best way to handle that situation? One possibility is to | > increase the threshold of system level id's (to 200? 300?), another is | > to check current reservation and clean long-term unused reservations (I | > doubt there are many such cases, so it's only temporary solution). Other | > could be sharing groups (as static uid's are still available), but | > that's not always good solution. | > | > Any other idea or some prefered solution? | | Simplest way is to bump the lowest number that's used for system IDs; | that may run into some collisions on older systems, though.
I just thought I'd grumble here.
In 1983, I assigned really high UIDs to my users (my family) on the first UNIX box I owned. 100 and up.
I really wanted the UIDs to be the same on all my boxes.
A couple of years ago, I tried Ubuntu. It would not let me keep those numbers. But Fedora would, with effort.
I gave up and renumbered on my newest boxes. It sure is a pain today when I'm trying to use NFS between an old box and a new one.
I think that Sun supports UID mapping on NFS but Linux does not.
It is also annoying when I move disks between systems. I guess I could use FAT :-)
On Friday 05 June 2009, D. Hugh Redelmeier wrote:
I gave up and renumbered on my newest boxes. It sure is a pain today when I'm trying to use NFS between an old box and a new one.
I think that Sun supports UID mapping on NFS but Linux does not.
It's supported with NFSv4. That might not help with old boxes though.
On 04/28/2009 03:04 AM, Ondřej Vašík wrote:
What's the best way to handle that situation? One possibility is to increase the threshold of system level id's (to 200? 300?)
I guess I've been blissfully ignorant and always assumed that id's under 500 were reserved for system use since Redhat systems have always created the first user uid as 500. Other admins I've worked with have been similarly misinformed, so you might get lucky here.
I wonder if a check for uid's between 100 and 500 could be added to smolt.
-Bill
Bill McGonigle bill@bfccomputing.com writes:
I guess I've been blissfully ignorant and always assumed that id's under 500 were reserved for system use since Redhat systems have always created the first user uid as 500.
I think it was 100 with early RHL. I'm sure I had to renumerate UIDs, most probably between RHL versions Or was that Slackware->RHL? Unlikely but possible.
Bill McGonigle wrote:
On 04/28/2009 03:04 AM, Ondřej Vašík wrote:
What's the best way to handle that situation? One possibility is to increase the threshold of system level id's (to 200? 300?)
I guess I've been blissfully ignorant and always assumed that id's under 500 were reserved for system use since Redhat systems have always created the first user uid as 500. Other admins I've worked with have been similarly misinformed, so you might get lucky here.
id's under id 500 are system id's and first user id is 500. That's correct - those defaults are coming from /etc/login.defs. However - id's under 100 are handled differently in some cases (e.g. default umask in /etc/bashrc and /etc/cshrc). And those id's are assigned statically and reserved by uidgid file coming from setup package. Increasing threshold in setup could cause some conflicts, but it's probably easiest way.
Greetings, Ondřej Vašík
devel@lists.stg.fedoraproject.org
-
Bill McGonigle -
Bill Nottingham -
Colin Walters -
D. Hugh Redelmeier -
Krzysztof Halasa -
Ondřej Vašík -
Ville Skyttä