4

The legacy systems has UID numbers up until the low 2000s. In implementing a new user management system, I am looking into options to avoid UID collisions.

One option is to just have a list of UIDs that cannot be re-assigned. I am currently looking into that.

Another much easier option would be to use a higher range (3000+). Any concerns I should keep in mind?

This would be on RHEL5, RHEL6 and RHEL7.

  • 2
    UIDs are typically 16 or 32 bit integers. Nothing wrong with just starting at 3000 serverfault.com/questions/105260/how-big-in-bits-is-a-unix-uid – spuder Mar 21 '15 at 19:07
  • I don't know about RHEL, but on Debian, a small range very high up (60k-65k) is used by some packages. Something similar may happen on RHEL, but I must stress my unfamiliarity with RHEL in this situation. – muru Mar 21 '15 at 19:29
  • On RHEL it's highly unusual for a UID to be above 500. Below 500 is considered the system user ID range, above that are for human users. One exception is nfsnobody which is 65534 – Bratchley Mar 21 '15 at 21:05
4

All Unix systems have at least 16-bit user IDs, which can take values from 0 (reserved for root) to 65535 (reserved as an invalid value). Many modern flavors (including Linux) support larger values, but in a mixed network, you should avoid these unless you're sure that all operating systems, filesystems and network protocols support them (e.g. older versions of NFS didn't). There's a general convention in the Unix world that “small” values are for the system and “large” values are for the administrator. “Small” and “large” are not defined precisely; the threshold is typically 100, 1000, or somewhere in between. Furthermore 65534 is by convention the user nobody, who doesn't own any file and doesn't run any system service (it's used for tasks that should not have any privileges, such as locate implementations that only index world-accessible files).

The upshot is that any value between 1000 and 65533 is safe. This goes for group IDs as well.

In networks, it's common to use a low part of this range for machine-specific accounts, and a high part for network-wide accounts. If several authorities create user accounts, they may use different ranges, e.g. 10000–19999 and 20000–29999. In your case, it's fine to decide that, say, the range 1000–2999 is for the legacy system and 3000–4999 is for the new system. Or that 1000–9999 is for the legacy system and 10000–19999 for the new system.

  • I think GNU/Linux at least has been on at least 32bit integers for a while. For example, freeipa has defaulted to 200,000+ since version two in an effort to be far above any reasonable point of collision. – Bratchley Mar 21 '15 at 21:00
  • @Bratchley You're right, it does, I've corrected my answer. It's still better to stick to 16 bits in this context (a potentially heterogeneous network), in case there's a need to support older systems or older protocols. – Gilles 'SO- stop being evil' Mar 21 '15 at 21:06
2

The Linux Kernel 2.6 and above supports unsigned 32-bit integers as UIDs and GIDs. This means the maximum UID should be 4294967294 (4294967295 is reserved) for RHEL4+ but it may depend on the system settings and utilities installed, specifically shadow-utils. You can test it out by trying a large UID, the only thing that would happen is it will reject it (try anything between than 65536 and 4294967294 on RHEL5). On RHEL6 anything above 4294967294 will just be rejected:

# useradd -u 4294967295 test
useradd: invalid user ID '4294967295'

RHEL6 and RHEL7 definitely support 32-bit with their utilities. I can't speak for RHEL5 because I don't have any boxes that are still on RHEL5.

So if your goal is to avoid any possible conflicts, you might want to start with something like 100000.

Just extra information: With the most recent kernel releases, using 4 billion UIDs isn't that far fetched because of user namespaces and unprivileged containers (reference docker, openvz, and lxc). As far as I know, RHEL does not support user namespaces yet, but they had announced that they were planning to with RHEL7 so I imagine it will be backported in sometime soon.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.