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

From Helpful
Jump to: navigation, search
m (mode)
m (mode)
Line 222: Line 222:
 
| regular file
 
| regular file
 
| S_IFREG, 0100000
 
| S_IFREG, 0100000
| <tt>-</tt>
+
| <tt style="font-size:x-large">-</tt>
 
|-  
 
|-  
 
| directory
 
| directory
 
| S_IFDIR, 0040000
 
| S_IFDIR, 0040000
| <tt>d</tt>
+
| <tt style="font-size:x-large">d</tt>
 
|-  
 
|-  
 
| named pipe, fifo
 
| named pipe, fifo
 
| S_IFIFO, 0010000
 
| S_IFIFO, 0010000
| <tt>p</tt>
+
| <tt style="font-size:x-large">p</tt>
 
|-  
 
|-  
 
| character special device
 
| character special device
 
| S_IFCHR, 0020000
 
| S_IFCHR, 0020000
| <tt>c</tt>
+
| <tt style="font-size:x-large">c</tt>
 
|-  
 
|-  
 
| block special device
 
| block special device
 
| S_IFBLK, 0060000
 
| S_IFBLK, 0060000
| <tt>b</tt>
+
| <tt style="font-size:x-large">b</tt>
 
|-  
 
|-  
 
| symbolic link
 
| symbolic link
 
| S_IFLNK, 0120000
 
| S_IFLNK, 0120000
| <tt>l</tt>
+
| <tt style="font-size:x-large">l</tt>
 
|-  
 
|-  
 
| socket
 
| socket
 
| (S_IFSOCK, 0140000)
 
| (S_IFSOCK, 0140000)
| <tt>s</tt>
+
| <tt style="font-size:x-large">s</tt>
 
|}
 
|}
 
Usually only need to care about regular files, directories, and the occasional symlink.
 
Usually only need to care about regular files, directories, and the occasional symlink.

Revision as of 16:48, 26 September 2012

Linux-related notes
Linux user notes

Shell, admin, and both:

Shell - command line and bash notes · shell login - profiles and scripts · Shells and execution ·· find and xargs and parallel · screen and tmux
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 simpler than ACLs. Sometimes it's much less bother than ACLs, sometimes it requires serious contortion (which is probably one major reason ACLs are 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

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
chown frank:      afile.txt  # sets user to frank, group to frank's login group
chown :goats      afile.txt  # sets group to goats
 
chown -R frank dataDir      #recursive: changes entire subtree (files, directories)

Note that without the colon you change only user and not group.


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, it may be 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).

Accounts

Account management makes altering whatever files store the details (often at least <ttt>/etc/passwd</tt> (user list) and /etc/group (group list), and usually also the shadow files. (passwd and group used to store the password hash, but since these had to be system-readable, that made brute forcing easy. Shadow files make it easy for only the system to access the password hashes.) See also details on PAM.

Note that these system files are what the user name on a file is based on, and that the file entry itself only stores the UID for this lookup (same goes for groups). File permissions are inherently local to a computer unless those IDs are centralized.


Adding a user: useradd

useradd can create a user and edit an existing user's details. (This may alternatively/additionally be adduser)


You usually want to add the -m option to have the implied home directory actually be created. The contents of a generated home directory will be based on /etc/skel/ (verify).


The initial group a user is a part of either a group with the same name or the user, or something like users or students, if you have an admin that likes it that way, or are that admin.


Notes:

  • You could give a specific home directory to the command. Otherwise it will be created under the configured base directory (usually /home)
  • 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)
  • whether useradd creates the directory depends on configuration. Similarly, whether userdel deletes a home direcotory, mail spool and such depends on configuration

Changing passwords

You can change your password with
passwd
, and if you're root you can change other people's passwords. On systems that integrate with networked systems like NIS, you may need to use another executable (like
yppasswd
). A plain
passwd
tells you so, or is symlinked to it.


Group management

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 (part of your login info)
  • your additional group membership (part of your login info)
  • a process's current effective group
    • your shell has a currently effective group - which likely is your primary group, unless you switched


Because of the way processes historically work, the mental model is a littly hairy.

Lazy and older programs may test only for the current effective GID (and UID). Checks for additional memberships isn't the same. (verify)

The easiest tool to see a user's currently effective GID, and additional memberships is probably
id
.

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),
6(disk),10(wheel),11(floppy),18(audio),20(dialout),26(tape),27(video)


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.


Note there is a
sg
, analogous to but for groups: it sets a different group for executing a particular command.

Group administration

Create or remove a group:

  • groupadd groupname
  • groupdel groupname
  • groupmod
    to change the name, or gid (group ID)

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


Change a user's primary group ('initial login group'):

  • usermod -g name_or_number username
    -- set primary group.
    • Warning: this also removes all other group memberships. Look at -G to re-add them.
    • Files under the user's home directory with the old GID will be chowned with the new GID
  • usermod -G name_or_number1,name_or_number2
    set (not add) additional group memberhips
  • usermod -a -G name_or_number1,name_or_number2
    add additional group memberships (more recently added - may not apply to you)


Change a user's additional groups membership:

  • gpasswd -a user group
    to make a user the member of a group
  • gpasswd -d user group
    to remove a user's group membership


Further group management:

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

Guts you can usually avoid

mode

Programmers may find it interesting that the permission bits mentioned are a subset of the mode, which is a larger integer.

Most things only show the lower so-many bits:

  • permission bits (lowest 9 bits)
  • sticky (S_ISVTX, usually 1000)
  • setgid (S_ISGID, usually 2000)
  • setuid (S_ISUID, usually 4000)

The mode also records the file type (obviously unchangable), is often 32-bit, and may store various OS-specific bits you can only get at via OS-specific libraries.

Various file types (text representation of mode, name, )

what constant 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

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
41777

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


Having 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 (regular permissions)
  • a file ./1/2/contents.txt

Then:

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


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

Permissions have been extended by:

  • setuid (SUID), shown in the user's execute position, 4000 in octal
  • setgid (SGID), shown in the group's execute position, 2000 in octal
  • sticky bit, shown in other's execute position, 1000 in octal

In chmod, you can add/remove them using u+s, g+s, o+t

In ls (and other places that show the file's mode as text), they show up instead of the x field. When the X permission is missing, they are shown in uppercase.



Setuid and setgid are security tools.

Some background: Every program runs with an effective user and group, which under regular circumstances is the user that executes the executable.

This also means the program can read exactly what the user can, which makes it simple and sensible behaviour

It 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 SGID, once a program starts executing, it takes the user ID or group ID from the file's directory entry, which implies different access. Sometimes more (such as setuid root, e.g. for svgalib programs), sometimes less (e.g. starting a service as root but having it run as an unprivileged user).

(These (setuid and setgid, and the related seteuid and setegid) are system calls which you can generally 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.

umask

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 shell's init script, e.g. ~/.bashrc

ACLs

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

ls
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


SUID, SGID


chroot jails


The graphical run-as-root wrapper is
gksu
, or
kdesu
(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).