UID/GID allocation: Difference between revisions
(→Rules) |
|||
Line 99: | Line 99: | ||
=== Linux conventions === | === Linux conventions === | ||
The [ | The [http://en.wikipedia.org/wiki/Linux_Standard_Base Linux Standard Base] Core Specification specifies that UID values in the range 0 to 99 should be statically allocated by the system, and shall not be created by applications, while UIDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts. See also [https://refspecs.linuxfoundation.org/LSB_3.0.0/LSB-Core-generic/LSB-Core-generic/uidrange.html LSB 3.0, Section 9.3: UID Ranges]. | ||
In practice, Linux distributions start allocating local regular user IDs from either 500 (Red Hat) or 1000 (SUSE, Debian). On many Linux systems, these ranges are specified in <code>/etc/login.defs</code>, for <code>useradd</code> and similar tools. | In practice, Linux distributions start allocating local regular user IDs from either 500 (Red Hat) or 1000 (SUSE, Debian). On many Linux systems, these ranges are specified in <code>/etc/login.defs</code>, for <code>useradd</code> and similar tools. | ||
Line 113: | Line 113: | ||
=== Personal groups === | === Personal groups === | ||
For each user, a corresponding group can be created that has the same name and numeric identifier, known as the '''personal group'''. Such personal groups have no other members and make collaboration with other users in shared directories easier, by allowing users to habitually work with <code> | For each user, a corresponding group can be created that has the same name and numeric identifier, known as the '''personal group'''. Such personal groups have no other members and make collaboration with other users in shared directories easier, by allowing users to habitually work with <code>umask 0002</code>. This way, newly created files can have by default write permissions enabled for group members, because this will normally only enable write access for members of the personal group, that is only for the file's owner. However, if a file is created in a shared directory that belongs to another group and has the setgid bit set, then the created file will automatically become writeable to members of that directory's group as well. | ||
On many Linux systems, the <code>USERGROUPS_ENAB</code> variable in <code>/etc/login.defs</code> controls whether commands like <code>useradd</code> or <code>userdel</code> automatically add or delete an associated personal group. | On many Linux systems, the <code>USERGROUPS_ENAB</code> variable in <code>/etc/login.defs</code> controls whether commands like <code>useradd</code> or <code>userdel</code> automatically add or delete an associated personal group. |
Revision as of 15:22, 10 September 2014
The departmental Unix LDAP server (ldap-serv1.cl.cam.ac.uk, etc.) export lists of users and groups, equivalent to the local Unix files /etc/passwd and /etc/group. This page is a draft policy for how in future the numerical user and group IDs exported by the departmental Unix LDAP server (ldap-serv1.cl.cam.ac.uk, etc.) should be allocated.
One important goal of this policy is to ensure that self-managed machines can import the user and group tables offered by the departmental LDAP servers without risking collisions with entries defined locally on the client machine by the operating system or the user.
Rules
- The LDAP server should not export any numeric UID or GID with a value below 1100.
- This mainly helps to avoid numeric collisions with UID and GID allocations by operating systems, which can cover the whole range 0-999.
- This helps to avoid collisions with locally created users (e.g., family members on a private laptop), which which some operating systems allocate starting at 1000 upwards.
- The LDAP server should also not export any numeric UID or GID of -2, -1, 32767, 65534, or 65535.
- This helps to avoid collisions with the POSIX return value -1 of some related system calls, as well as with the entry "nobody" used on some systems.
- Files stored on the departmental file space should avoid using any numeric UID or GID value below 1100, as the meaning of allocations in this range can differ between NFS client machines.
- Departmental numeric UID and GID allocations should preferably use 4-digit numbers until the available space is exhausted.
- just looks neater in "id", etc. than 5-digit numbers
- UID and GID allocations should be grouped together by type (regular users, pseudo-users, etc.)
- This is mostly for the benefit of users who see lists of UIDs and GIDs sorted by numeric value, e.g. with the Unix "id" command or in administrative tools and tables.
- For each user name and numeric UID, the corresponding identical group name and numeric GID should only be used for a personal group.
- Names of users and groups should be chosen to avoid likely collisions with operating-system allocations, e.g. check avoid common software/service names and compare e.g. against existing FreeBSD system user names and FreeBSD system group names; if necessary add some prefix (e.g., cl-) or suffix (-cl).
UID range allocation
- 0000-0999: not used in LDAP, reserved for OS-specific system entries or client-specific user entries
- 1000-1099: not used in LDAP, reserved for client-specific user entries
- 1100-4999: departmental users (real people)
- 5000-5499: departmental pseudo users (role accounts, daemon accounts, group accounts, etc.)
- 5500-5999: not used by LDAP, to avoid collisions of corresponding personal groups with departmental groups
- 6000-8999: departmental users (real people)
- 9000-: reserved
GID range allocation
- 0000-0999: not used by LDAP, reserved for OS-specific entries or personal groups of client-specific user entries
- 1000-1099: not used in LDAP, reserved for personal groups of client-specific user entries
- 1100-5499: departmental personal groups associated with the corresponding UID name and value
- 5500-5999: departmental groups
- 6000-8999: departmental personal groups associated with the corresponding UID name and value
- 9000-: reserved
Migration of legacy entries
As of 2014-09-10, there are still 53 UIDs and 103 GIDs allocated in the LDAP tables in the range 0-1099. There is also one regular user at 5187 They should all be moved to higher 4-digit positions eventually, according to the new scheme. However, some cause more problems than others, or are easier to move than others, and should therefore be prioritized.
- existing departmental groups in the range 500-999 can be moved to 5500-5999 by adding 5000 to their GID
- existing departmental pseudo-users (and associated personal groups) in the range 500-999 can be moved to 5000-5499 by adding 4500 to their UID/GID:
weather:501:dtg weather data gathering user dtg-backup:502:dtg data backup user qosmos:503:qosmos box file transfer user wwwsvn:505:WWW SVN user id nprobe:506:nprobe pseudo-user dtg-time:507:DTG TIME project apache-fp:509:apache fp wwwupdate:510:WWW updater ivc:511:ivc pseudo user ucard:512:University Card Office sec-repos:519:Security group svn repository ugprac:561:Undergraduate Practicals energy:591:Energy logs from monitors keytab:596:keytab www-cl:888:Local www server
- particular care is needed where existing departmental groups collide numerically with existing departmental pseudo-users and their personal groups:
502: dtg-backup = epson 507: dtg-time = lt-video 509: apache-fp = diss-upload
- existing departmental regular users outside this allocation scheme should be moved to new 4-digit locations that would otherwise be allocated to the next new users, with particular priority to be be given to those in the range 101-128 (which is densely populated by Linux system users):
maj1:101:Martyn Johnson pb22:104:Piete Brooks acn1:107:Arthur Norman mjcg:110:Mike Gordon pr10:111:Peter Robinson jf15:128:Jon Fairbairn lp15:138:Larry Paulson ceb4:145:Caroline Blackmun gt19:178:Graham Titmus iml1:243:Ian Leslie gw104:244:Glynn Winskel ah12:260:Andy Hopper am21:300:Alan Mycroft fhk1:301:Frank King mr10:302:Martin Richards drm10:336:Derek McAuley jmb25:341:Jean Bacon rf10:344:Robin Fairbairns ejb1:412:Ted Briscoe aac10:432:Ann Copestake djg11:1004:David Greaves km10:1077:Ken Moody rmm1002:5187:Richard Mortier sqlcache:10001:Linux cache of SQL server data visitor1:11105:Visitor account 1 visitor2:11106:Visitor account 2 visitor3:11107:Visitor account 3 visitor4:11108:Visitor account 4 visitor5:11109:Visitor account 5 tlh20:15384:Tim Harris
Background information
Linux conventions
The Linux Standard Base Core Specification specifies that UID values in the range 0 to 99 should be statically allocated by the system, and shall not be created by applications, while UIDs from 100 to 499 should be reserved for dynamic allocation by system administrators and post install scripts. See also LSB 3.0, Section 9.3: UID Ranges.
In practice, Linux distributions start allocating local regular user IDs from either 500 (Red Hat) or 1000 (SUSE, Debian). On many Linux systems, these ranges are specified in /etc/login.defs
, for useradd
and similar tools.
Mac OS X conventions
Mac OS X allocates locally created users from 500 upwards and uses the UIDs and GIDs 0-999 for the operating system.
FreeBSD conventions
For both UIDs and GIDs, the range 0-49 is reserved for core OS allocations, and the range 50-999 can be allocated by package porters for use by specific software packages in the files ports/UIDs and ports/GIDs. See also FreeBSD Porter's Handbook, Section 6.26: Adding Users and Groups.
Personal groups
For each user, a corresponding group can be created that has the same name and numeric identifier, known as the personal group. Such personal groups have no other members and make collaboration with other users in shared directories easier, by allowing users to habitually work with umask 0002
. This way, newly created files can have by default write permissions enabled for group members, because this will normally only enable write access for members of the personal group, that is only for the file's owner. However, if a file is created in a shared directory that belongs to another group and has the setgid bit set, then the created file will automatically become writeable to members of that directory's group as well.
On many Linux systems, the USERGROUPS_ENAB
variable in /etc/login.defs
controls whether commands like useradd
or userdel
automatically add or delete an associated personal group.