How does the Linux kernel deal with UIDs and GIDs?

When I want to add a user to a system, does the kernel require some type of "registration" for this user (syscall?)? Does the kernel even care about which users are available in /etc/passwd or does it simply know about and deal with numeric values independently of that file's content?

  • 1
    Users could be from NIS, LDAP, or some other authentication mechanism. The kernel doesn't care about /etc/passwd.
    – jordanm
    Jan 15 '13 at 20:43
  • @jordanm I think it is an answer
    – dchirikov
    Jan 15 '13 at 20:51

For the kernel, a user or a group are just a number (the UID and GID) attached to a process and which are used to see if the process is allowed to e.g. read (really open(2)) a file (files carry UID/GID and permission bits around for this very purpose), and also other operations (e.g., processes can manipulate processes belonging to the same UID). There are system calls to change UID/GID of the calling process (setuid(2)/setgid(2) and friends). Obviously, there are severe restrictions on who can use them.

The system can use the numbers to look up names from /etc/passwd, /etc/group or a slew of other mechanisms (LDAP, NIS, others), but that is strictly for human consumption.

When you log in and give your username, a program (running as root, and so alowed to do a lot of things normal users aren't allowed) takes the username and looks up the UID (to see if that user exists in the first place), asks for the password (or some other authentication) and checks it. If all goes well, the program changes to that UID/GID and exec(2)s the user's shell (which again is just a run-of-the-mill program, exactly which one to start is part of the user's account description).

  • 2
    You forgot to mention the list of supplementary group IDs, which are also (like uid and gid) attributes of a process, initialised by userland applications (login, su, sudo, login managers...) from the user and group database using the setgroups system call and also used to determine access permissions. Jan 16 '13 at 13:07

The kernel does not care about /etc/passwd. Not all authentication is done using an /etc/passwd file. User information can come from NIS or LDAP for example.


The check you're looking for is in acl_permission_check() in fs/namei.c. It just checks raw user and group ID values for the user making the system call against the values found in the file's inode.

For a normal POSIX filesystem, the full call path is:

  • open(2)
  • sys_open()
  • do_sys_open()
  • do_filp_open()
  • finish_open()
  • may_open()
  • inode_permission()
  • generic_permission()
  • acl_permission_check()

For other filesystem types (e.g. FAT) the call chain may vary due to lack of inodes, permission bits, and such.

The kernel doesn't care where the user and group IDs come from, or what their actual values are.

  • Does POSIX specify the names of internal kernel functions? Dec 25 '19 at 5:37
  • @G-ManSays'ReinstateMonica' I think their use of "POSIX" here refers to the filesystem rather than to the actual functions called.
    – Kusalananda
    Dec 25 '19 at 8:05

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.