Editing User identifier (section)

== Process attributes ==
The POSIX standard introduced three different UID fields into the process descriptor table, to allow privileged processes to take on different roles dynamically:

===Effective user ID===
The effective UID (<code>euid</code>) of a process is used for most access checks. It is also used as the owner for files created by that process. The effective GID (<code>egid</code>) of a process also affects access control and may also affect file creation, depending on the semantics of the specific kernel implementation in use and possibly the [[Mount (Unix)|mount]] options used. According to [[BSD Unix]] semantics, the group ownership given to a newly created file is unconditionally inherited from the group ownership of the directory in which it is created. According to [[AT&T]] [[UNIX System V]] semantics (also adopted by [[Linux]] variants), a newly created file is normally given the group ownership specified by the <code>egid</code> of the process that creates the file. Most filesystems implement a method to select whether BSD or AT&T semantics should be used regarding group ownership of a newly created file; BSD semantics are selected for specific directories when the S_ISGID (s-gid) permission is set.<ref>{{man|1|chmod|Solaris}}</ref>

====File system user ID====
Linux also has a file system user ID (<code>fsuid</code>) which is used explicitly for access control to the file system. It matches the <code>euid</code> unless explicitly set otherwise. It may be [[Superuser|root]]'s user ID only if <code>ruid</code>, <code>suid</code>, or <code>euid</code> is root. Whenever the <code>euid</code> is changed, the change is propagated to the <code>fsuid</code>.

The intent of <code>fsuid</code> is to permit programs (e.g., the [[Network File System|NFS]] server) to limit themselves to the file system rights of some given <code>uid</code> without giving that <code>uid</code> permission to send them signals. Since kernel 2.0, the existence of <code>fsuid</code> is no longer necessary because Linux adheres to [[Single UNIX Specification#2001: Single UNIX Specification, version 3, POSIX.1-2001|SUSv3]] rules for sending signals, but <code>fsuid</code> remains for compatibility reasons.<ref name='Kerrisk'>Kerrisk, Michael. ''The Linux Programming Interface''. No Starch Press, 2010, p.  171.</ref>

===Saved user ID===
The saved user ID is used when a program running with elevated privileges needs to do some unprivileged work temporarily; changing <code>euid</code> from a privileged value (typically <code>0</code>) to some unprivileged value (anything other than the privileged value) causes the privileged value to be stored in <code>suid</code>. Later, a program's <code>euid</code> can be set back to the value stored in <code>suid</code>, so that elevated privileges can be restored; an unprivileged process may set its <code>euid</code> to one of only three values: the value of <code>ruid</code>, the value of <code>suid</code>, or the value of <code>euid</code>.

===Real user ID===
The real UID (<code>ruid</code>) and real GID (<code>rgid</code>) identify the real owner of the process and affect the permissions for sending signals. A process without superuser privileges may signal another process only if the sender's <code>ruid</code> or <code>euid</code> matches receiver's <code>ruid</code> or <code>suid</code>. Because a [[child process]] inherits its credentials from its parent, a child and parent may signal each other.