Difference between revisions of "Linux admin notes - users and permissions"

From Helpful
Jump to: navigation, search
m (useradd, usermod)
m (useradd, usermod)
Line 176: Line 176:
'''On groups''':
'''On homedir''':
Often, default is to create a group of the same name, and add the user to it.
If you want users to go to a shared group instead, you can control this via arguments and, often, configuration files (see the man page for your system to be sure) like:
Line 196: Line 187:
: Not having a password set ''usually'' also disallows logins, at least remotely{{verify}}.
: Not having a password set ''usually'' also disallows logins, at least remotely{{verify}}.
:: (This can be useful to e.g. have users for [[samba]] to map to, but to not allow them to shell into the same server)
:: (This can be useful to e.g. have users for [[samba]] to map to, but to not allow them to shell into the same server)
'''On groups''':
Often, default is to create a group of the same name, and add the user to it.
If you want users to go to a shared group instead, you can control this via arguments and, often, configuration files (see the man page for your system to be sure) like:
===Changing passwords===
===Changing passwords===

Revision as of 16:07, 25 August 2016

Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts ·· find and xargs and parallel · screen and tmux ·· Shell and process nitty gritty

Linux admin - disk and filesystem · Init systems and service management (upstart notes, systemd notes) · users and permissions · Debugging · security enhanced linux · health and statistics · kernel modules · YP notes · unsorted and muck

Logging and graphing - Logging · RRDtool and munin notes
Network admin - Firewalling and other packet stuff ·

Remote desktops
VNC notes
XDMCP notes

...particularly in the context of filesystems

Filesystem permission basics

Most people know the below to some degree, and should.

'nix file permissions are a simpler system ACLs.

Which sometimes makes them easier to deal with, and sometimes requires serious contortion - which is one reason ACLs slowly being introduced into unices here and there.

Each filesystem entry (files, directories, other) has a set of properties. The most interesting are:

  • the user id (ususally shown as the name, as it is looked up on the current computer)
  • the group id (ususally shown as the name, as it is looked up on the current computer)
  • read, write, execute permissions bits for the owning user
  • read, write, execute permissions bits for the owning group
  • read, write, execute permissions bits for other - things that apply for everyone.

You can also get and set these numerically, as explained further down.

Permission bits are shown in various ways. The form form is the output used by
ls -l
. Its output for a regular file could look like:
-rw-r--r--  1 sarah users 2414 Nov 21  2004 afile.txt

The first bit shows permission bits (and more, explained later). You should read this as a special flag/filetype field, followed by three group of rwx, one for each of user, group, and other. For example:

- rw- r-- r--

The permission is present if the letter is present. In this case, sarah can read and write, anyone in the users group can read, and anyone else can also read this file.

'Other' is used for minimal permissions, since it always applies (regardless of what user or group id a visiting user comes along with), so -rw----r-- has a very similar effect in to -rw-r--r--.

Details explained later:

  • setgid and setuid are also be indicated in those letters
  • rights work slightly differently on directories

Notes: Seeing a plus sign, e.g.

-rw-r--r--+ 1 sarah users 2414 Nov 21  2004 afile.txt

...means that there are ACLs on this listing. See them with things like getfacl

Changing permissions

When changing permissions on a file there are various ways of describing permissions. One common distinction is whether you specify what should change or whether you specify exactly what the new permission set would be.

There are also different ways of describing each permission, and different operations to the permission bits. Choose the one or two you like.

Common usage:

chmod o-rwx afile.txt            # takes all permissions away from other
chmod +x afile.txt               # gives everyone execute permission
                                 # (short for a+x or the equivalent ugo+x)
chmod ug+w -R dataDir            # Gives user and group write permission

It is technically also possible to combine operations:

chmod a-rwx,u+wr,g+r -R dataDir  # A much-at-once style (not seen used much, but useful)
chmod u=rwx,go=rx dataDir        # Set-to-exactly-this style, in this case rwxr-xr-x

The numeric way sets permission bits as octal numbers, and is the shortest way to set all bits in one go. Where r=4, w=2, x=1:

chmod 0777 somefile              # gives full permission to all, like a=rwx.
chmod 0620 somefile              # sets rw- r-- ---
chmod 0750 somefile              # sets rwx r-x ---

...and any other combination. Most people remember just a few cases, such as 0777 as 'allow all', 600 (owner readwrite) or 644 (owner readwrite, others read-only) for files, 755 or 700 for directories, or such.

The leading zero is usually not necessary for command line utilities, since they know to interpret numbers as octals. In code you will usually need to use them, as otherwise they won't be understood as octal numbers.

Note that execute permissions on a file will include it in command autocompletion in shells. It will also allow execution as a binary, according to the hashbang, or using /bin/sh (as a fallback).

Changing ownership

You can change the user, group and each of these permissions, with chown and chmod respectively:

chown frank:goats afile.txt  # sets user to frank, group to goats
chown frank       afile.txt  # sets user to frank, leave group unchanged
chown frank:      afile.txt  # sets user to frank, and group to frank's login group
chown :goats      afile.txt  # sets group to goats
chown -R frank dataDir      #recursive: changes entire subtree (files, directories)

For more details on groups, see #Groups.

chown: changing ownership of `/path': Operation not permitted

Only the file/directorory's owning user (and root) can alter user or group membership.

You may expect that the file/dir's owning group can do so too, if it has write access to the file/dir. It can't. The reason seems to be practical one - it makes it easy to give away files that aren't yours, and/or that you can't get back. (is there some reason based in quota systems?(verify))

If you are the owning user (or root) and still can't, it's probably that the immutable attribute is set. See lsattr and chattr.

It may be that SELinux is prohibiting you (even if you're root).

You may be using a non-*nix filesystem, one which does not store file permissions (e.g. FAT).

Extended file attributes

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


By default, account information is backed by /etc/passwd (user list) and /etc/group (group list), and usually also the shadow files.

Note that filesystems store UIDs and GIDs, not usernames and group names, meaning filesystem permissions are inherently local to a computer unless those IDs are centralized / synchronized. This also matters to network filesystems such as NFS

useradd, usermod

adds a user
is a wrapper in Debian and derivatives (e.g. Ubuntu) which adds configurable site-specific configuration, making some things easier.
You may wish to use only adduser to avoid confusion.
(though I can never remember which name is which, but man is your friend)
changes details.

Most people user them so rarely that we just look at the man page.

On homedir:


  • useradd isn't always configured to create the user's home directory.
you'll want
useradd -m
(as it's more convenient than manually copying from /etc/skel/ and fiddling with the permissions)
  • (Similarly, whether userdel deletes a home directory, mail spool and such depends on configuration)
  • not having a home directory means the account cannot log in (as does not having a valid shell).
Not having a password set usually also disallows logins, at least remotely(verify).
(This can be useful to e.g. have users for samba to map to, but to not allow them to shell into the same server)

On groups:

Often, default is to create a group of the same name, and add the user to it.

If you want users to go to a shared group instead, you can control this via arguments and, often, configuration files (see the man page for your system to be sure) like:


Changing passwords

. If you are root you can change other people's passwords with it. On systems that integrate with networked systems like NIS, you may need to use another executable (like
). A plain
may tell you so - or may be symlinked to what you need to use.

To not allow password login password, use passwd -l. This prepends something (!) at the start of the hash value, meaning no password will ever work. It also means you can unlock (passwd -u) by removing that character again (avoids having to set/remember the hash).

Keep in mind that -l applies only to this type of password login. SSH logins may have their own rules, and may effectively bypass it depending on how it is set up, and on how a user is trying to authenticate.

You may be able to set the hash of a blank password - as in 'accept pressing enter for a password'. While passwd probably won't allow it, you can generate the appropriate hash value via mkpasswd. This is generally a bad idea, though. If you want passwordless remote login, look at using a passphraseless keypair.

Deleting (passwd -d) seems to (usually? always?) mean a blank password (verify) - if so, you rarely want this.

Keep in mind that anyone with root rights can su to any user, regardless of whether they are allowed remote or local login.


Theory: group logic

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

A user can be a member of more than one group.

Some important distinctions:

  • your primary group, a.k.a. initial login group
    • part of your login info
  • your additional group memberships
    • part of your login info, can be queried, but not everything does (verify)
  • a process's current effective group
    • your shell also has a currently effective group - which likely is your primary group, unless it was explicitly forced to be something different.

The easiest command line tool to see a user's currently effective GID(verify), and collection of all group memberships is probably

For regular users it may be as simple as:

uid=1004(sarah) gid=100(users) groups=100(users)

Root gets around more, and may look like:

uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),

Because of the history of the way processes work, the mental model and the code is slightly hairy.

Lazy and older programs may test only for the current effective GID and UID. A process can checks for additional memberships, but have to care, and have to know how to do it.

To change one's own currently effective group (in the shell), use
newgrp groupname
  • If you are a member of that group. it will switch without question.
  • If you are not a member, it will either deny you or ask for the group password, depending on how the group admin has set up the group.

There is a
[1], analogous to but for groups: it sets a different group for executing a particular command.

Practice: Group administration

groupadd groupname
groupdel groupname
, and sometimes
to change the name, or gid (group ID) [2]

Note that adduser may be configured to add a group with the same name as the user it creates (is this usually /etc/adduser.conf?(verify)), OR to have a default group to add everyone to.

(Other group management most people don't use:
gpasswd group
to set the group password,
gpasswd -r group
to remove the password,
gpasswd -R group
disables the ability for non-members to use password login. This can be done by a group admin and root. Group admins are one or more (non-root) users who are allowed to change group membership. Group admins are added to groups by root, using
gpasswd -A user group

group membership:

  • set primary group, a.k.a. initial login group
    • Warning:
      usermod -g group username
      works but also removes all other group memberships. Look at -G to re-add them if you did that.
      • Files in the user's home directory will be chowned from the old to the new GID(verify). The rest of the filesystem is unchanged, so you will have to do that yourself.
  • Change additional groups:
    • usermod -a -G group1,group2 user
      add additional group membership(s)
      • -a is a relatively recent feature, so you may not have it, in which case you may need to use...
    • usermod -G group1,group2 sets additional group membership to exactly this list, so be careful
    • gpasswd -d user group1
      to remove a user's group membership

Note: In almost all cases you can specify either the group's name or its GID.

Other notes

Creating homedir after user creation

Duplicate UIDs

Change UID

/etc/passwd, /etc/shadow, /etc/groups

These are plain-text, colon-delimited databases containing all information about users, passwords, and group membership.

Password shadowing describes system that separate out publicly fetchable information, and store the actual password hash in a separate file.

It's generally best to modify these with system utils like useradd, usermod, userdel, groupadd, groupmod, groupdel, chpasswd (changing password), gpasswd (changing group membership), chfn (change finger/CEGOS field), chsh (change login shell), ...although there are a number of situations where you can get away with editing them directly.

There is also vigr and vipw.

/etc/passwd is a colon-delimited file that stores basic user information:

  • username (up to 32 chars?(verify))
  • password - in the old days this stored the password hash.
Nowadays it is typical to put the password hash in /etc/shadow (which general users/programs cannot read), and leave this file readable, because the rest of the fields are public and useful.
...so this field will contain something like an x to indicate the real password hash is stored in /etc/shadow (it seems other values have been used, like !(verify))
  • UID - user's numeric ID
  • GID - primary group ID, refers to entry in /etc/group
  • Sometimes called comment, sometimes called GECOS. (Used by finger, if you use it) May contain comma-separated sub-fields including the following (but there are deviations from this)
    • Real name
    • physical address (building, room)
    • phone number
    • other contact info - pager, fax, email address
  • home directory for user
  • login shell to be invoked

/etc/shadow stores the user's password hashes, and some further password-related information

  • username
  • password hash
    • *, x and ! all(verify) seem to indicate 'no password is valid'
    • nothing seems to mean 'no password is present' - which allows passwordless login (verify)
    • starting with $ indicates use of a non-default hash method, and typically starts by specifying which hash.

Apparenrly $1$ is MD5, $2a$ is Blowfish, $3$ is NT hash $5$ is SHA-256, $6$ is SHA-512. (there may be another $ in the value, splitting a salt from the hash)

  • date of last change (days since Jan 1, 1970)
  • minimum days before a next password change is allowed (0, i.e. no limitations, seems common)
  • days after which a password is expired, and change is forced on the next login (99999 basically means "won't expire")
  • amount of days before the previous entry that you get warnings (7 seems common)
  • number of days after expiry after which the account is actually disabled (rather than just forces password change)
  • absolute date of expiry (days since Jan 1, 1970)
  • reserved field


  • 99999 days after 1970 is somewhere in October of 2243.
  • Dates in ~2012 are around 15500
  • passwd
    to change the password
  • chage
    ('change user password expiry information') to change most other things, or list the details in a more friendly way.


  • group name
  • GID
  • password (if any) - though if you use password shadowing, it will be in /etc/gshadow
  • comma-separated list of group members (is this an exact mirror of /etc/gshadow?(verify))


  • group name
  • password
  • comma-separated list of group admins
  • comma-separated list of group members (is this an exact mirror of /etc/groups?(verify))


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


  • keeps track of, and limits, users's and/or groups's files
    • both their size (units of 1K blocks) and the number of inodes (usually less relevant)
    • There is a soft limit that you can cross with only a warning, for a configured grace period.
    • The hard limit cannot be crossed. Using both is nicer to your users, and usually you only care about order of magnitude anyway
  • applies per ext[234] filesystem
can work through NFS - clients will ask for quota at the server end (what you'ld want)
other filesystems vary:
XFS is slightly different.
ZFS has its own separate system
  • requires kernel support
  • isn't useful without its management tools
  • stores a record of the current use, in what it calls the index
(There is an old variant, but pretty much everyone will have be using v2 by now)

Setting up:

  • Make sure your kernel supports it (on modern *nix you can assume it)
  • Install the quota tools. Usually called quota. (There are additional tools, such as quotatool, that you may not need)
  • edit /etc/fstab to add usrquota,grpquota to the mount options of the filesystems you want a quotum on
    • you can use journaled quota when supported. This basically means you don't need to run
      after an unclean shutdown. It would involve adding
  • make sure the files to store the index exist in the root of each relevant filesystem. Either:
touch aquota.user aquota.group
, or:
use -c when you manually run quotacheck the first time
  • remount, to make usrquot,grpquota apply
For filesystems currently in use (e.g. root filesystem), using
mount -vo remount
is nice
Less-subtle variants: umount and mount, or reboot.
  • create the quota index, to account for existing contents:
    quotacheck -vgum mountpoint
    • note: -a on this and other tools means '...for all mountpoints for which we use quota', which can save typing
    • -v for verbose may be nice for feedback to you.
    • -u for users, -g for groups
    • -m without this, the tool will remount the filesystem read-only, which you may not like on a running filesystem (particularly your root filesystem). This option tells it to leave it read-write, but keep in mind that any file currently changing size will be incorrectly indexed.
    • -c for create the indices (alternative is creating empty files beforehand)
    • if it tells you it can't guess format from filename, use -F vfsv0 (or vfsv1 if supported and wanted)
  • Optional: run
    repquota -a
    to get a summary of the index we just made
  • start keeping track of(verify) and enforcing(verify) quota:
quotaon -v filesystem
you'll probably want to set that at bootup, e.g. in your init script

  • You may want to put
    quotacheck -mug mountpoint
    in your crontab to make sure the index doesn't go off much(verify)
There are warnings about using that on mounted filesystem. Not because it can corrupt things, but because if a user was handling a huge file just when the index was re-made, the quota can be off by that file's size until the next rescan
...so try to schedule for time of light use, like 4AM

Using - users:

  • quota
    display (-s makes for human-readable sizes)

Using - admin:

  • edquota user
    edquota -g group
    - interactively alter quota for user or group.
    • edquota -p user1 user2 user3 ...
      - copy quota settings from user1 to user2, user3, etc. Also works on groups. Sometimes quite convenient.
    • soft: max blocks/inodes the user may have before warning is issued and grace countdown begins.
    • hard: max blocks/inodes
    • 0 means no enforced limit
    • the grace period is the same for both


edquota -t 7 days
edquota user_or_uid
  • setquota
    is a non-interactive alternative, useful when automating things. Example:
    setquota -u -F vfsv0 quotauser 1048576 2097152 0 0 /
  • repquota mountpoint
    - report quota use per user. Use -g for groups. Use -s for human-readable sizes.
  • TODO: you probably want to automate quota setting for new users.

See also:

Quota over NFS

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

NFS supports it, though under some conditions you may "Input/output error" instead of "Disk quota exceeded"(verify) (I got the latter, though, so that seems to work too)


  • Server side:
    • Configure quota as usual
    • set up
      to run (...if you want client-side
      commands to work). This service may be called something else, such as rpcquota (verify)
  • Client side:
    • mount NFS as usual (no quota related mount options, they won't work)
    • add the -r option to edquota to make it contact the relevant NFS server (note: many other quota tools are local-only, so a habit of logging into the server may be easier)


Guts you can usually avoid


Programmers may find it interesting that the permission bits mentioned are a subset of the mode.

Mode is a larger integer (now often 32-bit), which stores:

  • permission bits (lowest 9 bits)
  • setgid (S_ISGID, usually 2000). In text representation it's in the group-execute field, an s if the group execute bit is set, or S if the execute bit is missing
  • setuid (S_ISUID, usually 4000). In text representation, see setgid, but for the user execute field/bit.
  • sticky (S_ISVTX, usually 1000). In text presentation, it's in the other-execute field. It's t if the execute bit is present, T if it is missing.
  • file type (see below, and these are read-only)

Most command line tools only show (and allow change of) permission, sticky, setuid, setgid,

The mode may also store OS-specific bits, which you can only get at via OS-specific libraries.

File types:

what constant (octal; may differ(verify)) in text representation of mode
regular file S_IFREG, 0100000 -
directory S_IFDIR, 0040000 d
named pipe, fifo S_IFIFO, 0010000 p
character special device S_IFCHR, 0020000 c
block special device S_IFBLK, 0060000 b
symbolic link S_IFLNK, 0120000 l
socket S_IFSOCK, 0140000 s

You usually only need to care about regular files, directories, and the occasional symlink.

You can get the full mode with a stat(), which is what library functions that test 'is this a directory' use, but even the command-line stat command masks out everything but the permissions bits unless you specifically ask for all of the mode bits.

It also shows it in hex for some reason, so to view the full mode in octal, you'ld have to do something like the following:

$ stat --format %f /tmp | tr [a-f] [A-F] | xargs --replace=@ echo "ibase=16; obase=8; @" | bc

directory permissions, read and execute

In terms of permissions, directories are seen as entires in the directory they sit in, like any other. At a lower level, they are files that record the directory's listing - more exactly, (name,inode) pairs. It is interpreted as a directory because it marked so in its mode.

This makes the following easier to follow and swallow:

  • read rights allow: reading references to fetch file details (verify)
  • write rights allow: create, rename, and remove files in it
  • execute rights allow: searching/listing its entries (the names)

At first sight, r and x are only useful in combination, and o+w is scary.

Instead of reading the below, you can just remember that in most any case, you want to assign/remove both r and x.

x withour r

...means you can't list the directory itself, but this is not recursive: if permissions on contained files allow and you can guess their names, you can read them fine, and if they're directories, change to them fine.

For example, if you have:

  • a directory ./1 with d-wx--x--x (result of chmod -r ./1)
  • a directory ./1/2 with drwxr-xr-x
  • a file ./1/2/contents.txt


$ ls 1
ls: cannot open directory 1: Permission denied
$ ls 1/2
$ cat 1/2/contents.txt
(whatever that file contains)

r without x

...means you can list that directory's entries and see their names, but not see file details (specifically, stat() them) or read contents, which therefore also disallows descending into directories.

For example, if you have

  • a directory ./1 with drw-r--r-- (result of chmod -x ./1)
  • a directory ./1/2 with drwxr-xr-x (regular permissions, same as before)
  • a file ./1/2/contents.txt
$ ls -l 1
ls: cannot access 1/2: Permission denied
total 0
?????????? ? ? ? ?            ? 2
$ cd 1
bash: cd: 1: Permission denied
$ ls  -l 1/2
ls: cannot access 1/2: Permission denied
$ cat 1/2/contents.txt
(whatever that file contains)
cat: 1/2/contents.txt: Permission denied

directory permissions, write

o+w permission is scary since it means that anyone can alter directory entries, even if those entries don't list the user as their owner.

The same applies to g+w if the group is something like 'users' or 'students' and that includes people you may not want to trust implicitly.

Sometimes you may want a directory which can be used to give each other files, or a generally shared directory.

directory permissions, sticky

Without sticky, you can share a directory only if you are in the same group, or allow write permissions to world.

When a directory has the sticky bit set, then this parent directory's owner and each directory entry's actual owner can rename and remove entries (anyone can create files/directories).

With sticky, people can work in the same directory, but can shield each other from accidentally (or purposefully) messing with files and directories they don't own.

/tmp is often a stickied directory for this reason.

(The sticky bit was named for its historical use on regular files, where it was a signal to the OS to keep this around in memory (or in local rather than remote storage), as it would probably be used regularly. Modern caching and drive speed has made this mostly obsolete. (I'm not sure whether modern kernels still listen to the sticky bit(verify))

setuid, setgid, and sticky on files

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)


  • the SUID and SGID bits will trigger seteuid / setegid syscalls at launch time, with the file's current user/group
  • "SUID root" is the typical case: chown as root, set suid bit, to have root permissions without need for sudo
can only be set that by root / through sudo (for obvious security reasons)
often for daemons, and only when starting up - they'll often use the same syscalls to give away root permissions (switch to a normal user) again

These bits are stored in the mode, on top of basic rwx permissions, are:

  • setuid (SUID), shown in the user's execute position, 4000 in octal, add with
    chmod u+s
  • setgid (SGID), shown in the group's execute position, 2000 in octal, add with
    chmod g+s
  • sticky bit, shown in other's execute position, 1000 in octal, add with
    chmod o+t
ls -l
they show up instead of the execute field field, e.g.
-rwsrwsr-t 1 root root  1191834 Nov 23  2013 thingie

(When they have these bits without execute, the S and T are shown in uppercase)

Some background: Every program runs with an effective user and group.

Under regular circumstances is the user that executes the executable, which means the program can do exactly what the user can, which is sensible default behaviour.

That doesn't serve all cases. Some things need to get at something more restricted to work, for just a second, or sometimes longer.

For example, svgalib needs root access to access graphics hardware directly, which would mean anything that needs svgalib is only useful when root runs it, or you're allowed to run it via sudo.

With SUID and/or SGID, once a program starts executing, it takes the user and/or group ID from the file's directory entry, and applies it to the process via setuid and setgid, and the related seteuid and setegid -- which are system calls which you can always use, it's just that the file permission flag is simple and serves many purposes.

Some actions that users may do but are technically low-level or restricted are often setuid or setgid (or allowed via sudo). This includes passwd, mount, umount, ping, and su.

Since you can't give away ownership (to, say, root), this isn't directly a security problem. However, you and particularly root should be careful of what they take ownership of; whatever files are owned by root, generally accessible, o+x and setuid or setgid will effectively run as root when executed by anyone, and therefore be able to do anything. There are a few fairly simple ways around this, such as to disallow directory access, which can be done by moving files you take ownership of to /root, when it has something like 0700 permissions - like it usually does.


In general, the Effective UID (EUID) is checked when checking whether a process has permissions for an operation, while the real UID typically describes which user started the process, basically who asked for the operation.

For typical programs they are the same. They can differ because this can be useful around elevated privileges, at which point they may wish to change their EUID. (Keep in mind this is mostly a bit of carefulness, but not a strong security feature, as it does not require authentication, and there is more than one way to get elevated rights)(verify)

It's also possible for a progam to change its UID (setuid()), but relatively few do, because in most cases it is doesn't matter to permissions, being more of a display, double-check, or better-impersonation thing.

For example, consider
and its root-owned password file.

While running it, the UID describes the user which ran it to alter their password, while the EUID will have to be root to write to the password file. For this reason, passwd is usually owned by root and has its setuid bit on in the filesystem mode, which means the OS will do the seteuid() call for it (and the effective authentication is the fact that only root could change the file ownership).

For another example, a webserver process started as root may wish to set its EUID before it does any filesystem accesses to satisfy a request.

The relevant underlying system calls:

  • geteuid()
  • getuid()
  • seteuid(uid_t euid)
  • setuid(uid_t ruid)


  • setreuid(uid_t ruid, uid_t euid) - can set both real and effective UID at once, or just one

There is analogous logic for the real and effective group (TODO: more explanation). The relevant system calls for it:

  • getegid()
  • getgid()
  • setegid(gid_t egid)
  • setgid(gid_t rgid)


  • setregid(gid_t rgid, gid_t egid) - can set both at once


This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

The umask removes permission bits from files and directories (programs running as) you create, from mkdir to whatever fanciness you are running.

You can always change them later - the point here is what protection you get by default.

Example: If the umask is 0022:

  • 0022 itself means --- -w- -w-
  • ...which are the things that are removed from permissions
  • in this case meaning that on newly created files, write permissions will never appear for group or other. Read and execute is not masked away, so other people can go into your directories and read files.

When people work in groups -- (but you still want at least processes to have a clear owner, so sharing a single account is not so useful), you might want to not mask anything from the group so that you can work with each others' data by default. Example: 0002 (or so),

If your group is something like 'students' or 'staff', you probably don't want group writability. You might use 0027 (no write on group, nothing on other), or perhaps 0077 if paranoid.

You can make this persistent by adding something like

umask 0002

to your ~/.bashrc (or whatever applies for your shell).


On newer systems, people are starting to use ACLs, in which case files and directories can have an ACL to them.

shows presence of ACLs with a + after the permissions string:
drwxr-xr-x+  2 root root      6 Dec  3  2003 opt
dr-xr-xr-x  43 root root      0 Nov 14 07:28 proc

I've not used these yet myself, but you can apparently use getfacl and setfacl to get and set these.

Changing UIDs and GIDs

Running with different credentials / reduced permissions

This article/section is a stub — probably a pile of half-sorted notes, is not well-checked so may have incorrect bits. (Feel free to ignore, fix, or tell me)

Know the permission details above.

See also su, sudo, sudoers


chroot jails

The graphical run-as-root wrapper is
, or
(GNOME and KDE variants). May be injected into the command when the system can guess you'll need it (particularly in Alt-F2 style launching).