Unix filesystem permissions

Tutorials

redhat permissions

https://www.redhat.com/sysadmin/suid-sgid-sticky-bit

Basics

Generally speaking, unix file permissions work as follows.

• files are owned by a user, and group
• combinations of read, write, execute permissions are granted to a file
  • the user who owns the file
  • the group who owns the file
  • anybody else
• file deletion is determined by parent directory

You can list files with their permissions using ls -l.

-rw-rw-r-- 1 root will 31744 Feb 21 17:56 start

Permissions

owner (chown)

chown owner:group myfile  # set owner/group of a file

permissions (chmod)

chmod 755 /my/executable   # set permissions for owner(7), group(5), other(5)

type	owner permissions	group user member permissions	other user permissions	Number of Hard Links	owner	group permissions apply to	file size in kb (by blocks)	Last Modified	FileName
-	rw-	rw-	r--	1	root	will	31744	Feb 21 17:56	start

The first column specifies the file type:

-	-- Regular File
d	-- Directory
l	-- Link
c	-- SpecialFiles (used for input/output)
s	-- Socket
p	-- Named Pipe
b	-- Block Device

0   # none
1   # x
2   # w
3   # wx
4   # r
5   # rx
6   # rw
7   # rwx

suid, sgid, stickybit

usage

chmod u+s file   # set suid
chmod g+s file   # set guid
chmod +t  file   # set stickybit

chmod 1777      # stickybit + 777
chmod 2777      # guid + 777
chmod 4777      # suid + 777

# sum octal numbers to combine them
chmod 3777      # (1 + 2) (stickybit + guid) + 777

on files

• if suid is set, the script runs as it's owner (no matter who executes it)
• if sgid is set, the script runs as it's group (no matter who executes it)
• stickybit on files is generally ignored (both Linux/BSD)

NOTE:

suid/guid is generally ignored on interpreted executables for security reasons (bash-scripts, python-scripts, perl-scripts, ...).

on directories

• by default, files/dirs created will be owned by creator, and assigned the group of the parent

• suid is normally ignored - at least on liux/freebsd
• if sgid is set, new files in subdirs will be owned by directory's group (this is just default behaviour...)
• if stickybit is set on a dir, only the owner (and root on linux) is allowed to delete it (regardless of other permissions)

chattr/chflags

TODO:

this is super vague. learn this properly and record. Are these extended-attributes?

chattr is used to set the immutable bit. This can help prevent accidental deletion of files, among other things.
It is only usable on filesystems that support it (ext2, ext3, ext4, ...).

For the BSDs, see chflags.

See https://en.wikipedia.org/wiki/Chattr

chattr (Linux)

chflags (BSD)

In addition to normal permissions, some filesystems (at least ufs/zfs) have an additional permissions bit; the immutable bit.

It can make it so that your file is unable to be deleted by root, is not dumped,

On linux, this is controlled using chattr, on bsd you use chflags .

ls -lo                  # ls, displaying immutable bit
chflags noschg <file>     # remove 'schg' setting in immutable bit
chflags schg   <file>     # set 'schg' immutable bit

schg     # no system user (owner, root, ...) can delete/rename/move file or it's immediate subdirectories/files
uchg     # owner cannot delete/rename/move file

sunlink  # 
uappnd   #

See https://en.wikipedia.org/wiki/Chattr for available attributes and explanations.

Cookbook

create/rename but no delete

If you set the sticky bit on the parent dir (and allow users to write files, ex: 777)
users (that don't own the parent dir) will be able to create, rename, and move (their own) directories but not delete them.
The owner that does own the parent dir will be able to delete files.

mkdir foo/
chmod 1777 foo/
chown root:wheel foo/

su other_user
mkdir  foo/somedir
mv     foo/somedir foo/_somedir_  # allowed
touch  foo/somedir/file.txt       # allowed
rm -rf foo/somedir                # NOT allowed