Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
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
add comment

3 Answers 3

up vote 2 down vote accepted

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

share|improve this answer
    
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. –  Stéphane Chazelas Jan 16 '13 at 13:07
    
Thanks for the clarification. –  vonbrand Jan 16 '13 at 14:49
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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