Editing User identifier (section)

===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>