UID/GID allocation: Difference between revisions

From Computer Laboratory System Administration
Jump to navigationJump to search
(first shot)
 
No edit summary
Line 1: Line 1:
=Departmental UID/GID allocation=
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.


This page is a draft policy for how in future the 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.
 
Goal of this policy is to ensure that self-managed machines can make of of the /etc/passwd and /etc/group tables exported by the departmental LDAP servers without risk of collisions with entries defined by the operating system or the user locally.


== Rules ==
== Rules ==


* The LDAP server should not export any numeric UID or GID with a value below 1005.
* The LDAP server must not export any numeric UID or GID with a value below 1100.
 
** This mainly helps to avoid 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.
** 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.
* 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.


** 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.
* Departmental numeric UID and GID allocations should use 4-digit numbers until the available space is exhausted.


* UID and GID range 0 to 999: is reserved for use by either operating system distributions, or user entries created locally on client machines without any corresponding LDAP entry
* UID and GID allocations should be grouped together by type
** 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.


* UID and GID range 1000-1005: reserved for user entries created locally on client machines without any corresponding LDAP entry
* For each user name and numeric UID, the corresponding group name and numeric GID should only be used for a personal group


== UID range allocation ==
== UID range allocation ==


* 0-999: not used by LDAP, reserved for OS-specific entries or host-specific user entries
* 0000-0999: not used in LDAP, reserved for OS-specific system entries or client-specific user entries
* 1000-1004: not used by LDAP, reserved for host-specific user entries
* 1000-1099: not used in LDAP, reserved for client-specific user entries
* 1005-1099: historic departmental allocations, can stay, but should not be reused
* 1100-4999: departmental users (real people)
* 1100-4999: departmental users (real people)
* 5000-5499: departmental pseudo users (role accounts, server accounts, etc.)
* 5000-5499: departmental pseudo users (role accounts, daemon accounts, group accounts, etc.)
* 5500-5999: not used by LDAP, to avoid collissions with departmental groups
* 5500-5999: not used by LDAP, to avoid collisions of corresponding personal groups with departmental groups
* 6000-8999: departmental users (real people)
* 6000-8999: departmental users (real people)
* 9000-: reserved


== GID range allocation ==
== GID range allocation ==


* 0-999: not used by LDAP, reserved for OS-specific entries or host-specific user entries
* 0000-0999: not used by LDAP, reserved for OS-specific entries or personal groups of client-specific user entries
* 1005-5499: personal groups associated with the corresponding UID name and value
* 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
* 5500-5999: departmental groups
* 6000-8999: personal groups associated with the corresponding UID name and value
* 6000-8999: departmental personal groups associated with the corresponding UID name and value
* 9000-: reserved


== Background ==
== Background ==
Line 57: Line 61:


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 [http://svnweb.freebsd.org/ports/head/UIDs?view=co ports/UIDs] and [http://svnweb.freebsd.org/ports/head/GIDs?view=co ports/GIDs]. See also [http://www.freebsd.org/doc/en/books/porters-handbook/ FreeBSD Porter's Handbook], [http://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.html Section 6.26: Adding Users and Groups].
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 [http://svnweb.freebsd.org/ports/head/UIDs?view=co ports/UIDs] and [http://svnweb.freebsd.org/ports/head/GIDs?view=co ports/GIDs]. See also [http://www.freebsd.org/doc/en/books/porters-handbook/ FreeBSD Porter's Handbook], [http://www.freebsd.org/doc/en/books/porters-handbook/users-and-groups.html 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 <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 writable 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.


== See also ==
== See also ==

Revision as of 14:17, 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 must not export any numeric UID or GID with a value below 1100.
    • This mainly helps to avoid 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 use 4-digit numbers until the available space is exhausted.
  • UID and GID allocations should be grouped together by type
    • 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 group name and numeric GID should only be used for a personal group

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

Background

  • Keeping the range 1000-1004 free of departmental allocations 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.
  • Avoiding -2, -1, 32767, 65534, and 65535 helps to avoid collisions with the POSIX return value -1 of some related system calls, as well as

Operating system conventions

Linux

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

Mac OS X allocates locally created users from 500 upwards and uses the UIDs and GIDs 0-999 for the operating system.

FreeBSD

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 writable 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.

See also