22853
Comment: syntax
|
22686
WIP wording, refactor
|
Deletions are marked like this. | Additions are marked like this. |
Line 19: | Line 19: |
* '''group''' - group of users the file belongs to | * '''group''' - group the file belongs to |
Line 22: | Line 22: |
To see what user and group you are, run {{{ id -a }}} in a [[Shell]]. '''uid''' will tell you who you are (as if you didn't already know this), '''gid''' is your "effective" group, and '''groups''' - all other groups your user belongs to. If a particular access permission is granted to one of the groups your user belongs to then you will be allowed access too. The effective group id is significant when creating files and directories, as explained below. For the record, when you login your effective group (and your "real" group) is set to your "primary" group -- the one group associated with your login in {{{/etc/passwd}}}. |
To see what user and group you are, run {{{ id -a }}} in a [[Shell]]: * '''uid''': your user name and id * '''gid''': your primary group name and id * '''groups''': all other groups your user belongs to. If a particular access permission is granted to one your groups, then it will be also be granted to you. Your '''effective'' group id (take into account when creating files and directories, as explained below), is most of the time set to your primary group id. |
Introduction
One of key factors to system security is access permissions control. All modern operating systems support this feature. It allows file owners to restrict who can read, write, execute and otherwise change files, running processes and other parts of the system.
Linux, as every UNIX-like OS, has a built-in file permission control system. It assigns the following attributes to every file on its file system:
owner - user who owns the file, has unlimited control over it and can change other file attributes
group - group the file belongs to
UNIX permissions - a set of rules defining who can do what with the file
To see what user and group you are, run id -a in a Shell:
uid: your user name and id
gid: your primary group name and id
groups: all other groups your user belongs to.
If a particular access permission is granted to one your groups, then it will be also be granted to you.
Your effective group id (take into account when creating files and directories, as explained below), is most of the time set to your primary group id. Used terms: file system - an on-disk structure holding descriptions of files (such as the attributes mentioned above, file modification date etc.) and the files' contents themselves. File systems are contained in disk user group - in UNIX-like systems, every user is assigned to some group. Users in the same group may share rights, for example a file's permissions may be set so that all users in a group can modify its contents.
Having learnt the theory, it's time to pass on to practice - what do UNIX file permissions look like and how to use them? First of all, let us examine the permissions of an example file. By issuing the following command in Linux console or a terminal emulator: you will see a list of file's attributes. It includes file type (it could also be a directory, a symlink, etc.), file size et cetera and a line like the one quoted below, which is the item of our interest: Obviously, the file is owned by the Therefore, number 5, for example, would mean: a permission to read and execute, but not to write. The digits define respectively: owner, group and others' permissions. Therefore, we can see that, in our example, file owner (root) may write to the file and read its contents, while group 'root' and other users (not being root nor a member of group 'root') are given the right to read the file.
Several system tools and graphical programs recognize the idea of a human-readable form - a string of 10 consecutive characters. To see an example, issue the command below: The -l flag tells ls to display file permissions in the left column of output. The full sequence that you might encounter is as follows (although you probably won't find such files in /etc): Now, let's divide this into parts. The first character defines node type, which is (rw- for owner, r-- for group, --- for others). The last column is the To access any path in the filesystem, the user (which the particular process is running as) needs at least execute privilege for all its parent directories. Therefore, if you try to access an
This section is included primarily for reference and to aid understanding. Default permissions and group assignment are not often changed so it is safe to skim over this section and come back to re-read it for more detail should the need arise. The permissions associated with newly created files and directories are, for the most part, determined by something called a umask. The umask is a 4 digit octal number that is subtracted from 0777 to produce the default permission associated with objects newly created in the filesystem. The umask of a 'stock' Debian system is 0022 which makes the default permissions be 0755 -- the owner has all permissions, the group read and execute but not write, and everybody else can read and execute but not write. One would then expect all newly created files to be marked executable but this is prevented because the system call that creates files defaults to creating files that are not executable. Directories on the other hand do have their execute bit set, umask permitting, and so by default can be traversed by all. The shell umask command can usually be used (without any arguments) to display the current default umask. The umask is set globally by the system administrator in one of various ways; the most elegant is probably the use of the ?PAM pam_umask module in /etc/pam.d/common-session. The system-wide umask may be overridden by each user. This is usually done in ~/.bashrc on a per-user basis, with the shell umask command on a per-process basis, or using the umask(2) system call from within a program. The user uid (user id number) associated with a newly created file or directory is that of the running process effective uid. In most cases this is the uid of the user who logged in and started the process. The group associated with a newly created file or directory is the effective group of the running process. This is normally the group named with the username of the logged in user, but can be manually changed (along with the "real" group) on a per-process basis with the newgrp command although this is rarely done. The first of the 4 octal digits which represent permissions contains the setuid and setgid bits. These can be used to override some of the defaults described above but it is not worth getting into details other than to note that the user private groups project collaboration idiom (see below) depends on the behavior of the setgid bit.
This section shows, using an example, the very basic usage of There is a special case: to clear special bits with directories, you must mention the file mode bits explicitly (in symbolic mode) or by operator numeric mode (in octal description) (see more with: 'info coreutils, section 27.5 "Directories and the Set-User-ID and Set-Group-ID Bits") Have the file permissions changed? You can verify that it actually worked by starting a new session and logging on to another user account, or issuing Now, log on to demo, open testfile (in your regular user's home directory) and type something in it. Save, and then check with your own user's account that it contains whatever you may have written. Voila! You may now want to check it with various different permissions. Try chmod with arguments like 644, 640 and so on.
You now know how to change file permissions. However, how can they be useful in real life besides letting your buddy leave you a random message in your own text files?
Note on below: In case files have a wrong group attribute set, you can correct it by first running
Examples above show the usefulness of UNIX file permissions. You can grant users from your group access to your files, expose them to the whole world or have them only for yourself. However, there are use cases in which this access control model is not enough. Assume that you are on a large system (perhaps a server) and, together with several dozen users you are members of group 'users'. Now, you want to make some of your files available to just one of them so that the others can not read it. How can UNIX permissions benefit you? You could use the user private groups directory sharing idiom; a common solution to this problem. But the user private groups idiom pushes the UNIX permission system to its limits and there are cases, even simple file sharing cases between 2 people, where the idiom is simply not suitable. When the limits of basic UNIX file permissions are reached it is time to make use of...
Access Control Lists (called ACL) are an extended means of defining access rights to files and objects. They allow you to specify file permissions in a more fine-grained way, assigning any user or group (besides owner and file's set group) different privileges. For instance, you may share a file with just one specific user, no matter what group they are in. How to make use of this new, powerful feature? Alternatively, you can use Synaptic package manager, or another package manager, to get and install the package. If you are not the system administrator, ask your sysadmin to enable ACL on your machine. If setfacl complains about an error, you probably need to mount your filesystem with Try should show, among others, a line like this: Here, Example uses of setfacl to manage file permissions
Note: a bug in coreutils commands cp and mv limits the scope of the below to pure file creation, e.g. with touch: with copy and move, the "Default mask" of the target parent directory won't be inherited as the "Access mask" for the copied/moved file/directory: http://debbugs.gnu.org/db/85/8527.html Default ACL are an invaluable tool when making a directory that you want to share for reading or writing among users. This hint is inspired by this thread on the Debian forums: http://forums.debian.net/viewtopic.php?f=10&t=53591 Default ACL are access control entries that get inherited by all sub-items of a directory (recursion deeper is allowed!). Thus, if you want to create a directory for Note to the above: a default ACL is inherited by all child nodes as an ACL entry and default ACL, but a default ACL on its own Now, whenever a file gets created, it retains its original owner and group, but should automatically get assigned the above ACL. This is, for example, useful when you have users co-working on website development. You can use Apache or PHP running as www-data, write a script to change file ownership upon creation to www-data (inotify helps!), and all files are still writable by bob and fred, your Web developers.
Then, 'otherguy' can just set their files to 07 Konqueror (at least in Debian Squeeze) supports ACL out-of-the-box when filesystems are mounted with Sometimes you have to mount a filesystem that does not support ACL. For example, a NFS volume exported by a central storage solution, or an userspace zfs diskset. In these situations, you can try one simple solution: http://cintrabatista.net/nfs_with_posix_acl.html You can find a wonderful but pretty old (still current, though) ACL guide here: http://www.vanemery.com/Linux/ACL/linux-acl.html That's all! Have fun and thanks for bearing with me. CategoryCommandLineInterface | CategorySystemSecurity | CategorySystemAdministration | ToDo: refactor Section 2: UNIX permissions explained
stat /etc/hostname
Access: (0644/-rw-r--r--) Uid: ( 0/ root) Gid: ( 0/ root)
Now, compare it to file permissions of /etc/shadow (use 'stat' again). This file has 0 as the third meaningful digit, so users not being root nor in group 'shadow' may not even read the file. You can easily confirm that by running a text editor and trying to open /etc/shadow - you, as a regular user, should not be allowed to see its contents as it contains system-wide passwords (and this is beyond the scope of this little How To). Human-readable form
ls -l /etc
-rwxrwxrwx+
rw-r-----
The defaults for new files and directories
Section 3: Modifying file permissions
# first of all, create the file using touch command (see 'man touch' for details)
touch testfile
# now, let's see its permissions
stat testfile
# modify the file so that group members and other users can write to it
chmod 666 testfile
# see the new permissions
stat testfile
su
(your root password here, to log on to root account and add a test user)
adduser demo
# you can remove this user when you've finished: deluser demo
Section 4: Example scenarios involving chmod
Case 1: Family photos
Situation: You store family photos in directory Photos on your user account. Several other family members use the computer and you want them to be able to access the photos. Question: How to set directory permissions so that other users can see your files and their content? Answer: Set the directory to 755 and all files under it to 644: chmod 755 Photos
# Photos/* means all files in Photos directory
chmod 0644 Photos/*
Case 2: Software and data files for your department at work
~ means your home directory. Situation: In your home directory you have a program in ~/AppSoftware/program.bin . It stores your department-specific data files in ~/OurData. The system operator has assigned you and other people in your department a user group 'mydept'. You want other people from your department to be able to run the provided software and to write the data files. At the same time, other people from outside the group should be allowed to run the software but not to modify the data. For simplicity's sake, we skip things like logging who added/removed what in terms of data (logging is a necessity in real life), focusing only on appropriate permissions. Question: How to allow execute access for a group to one file (program binary) and read-write access to other directory for the same group, while denying world (other users) access? Answer: In our example, this would be: # below: -R flag, affects the directory and files/subdirs inside
chmod -R 0755 ~/AppSoftware
chmod -R 0770 ~/OurData
Case 3: Classified files
Question: How to protect files that are to be kept secret? Answer: A very basic protection can be achieved by chmodding the sensitive files/directories to 0600. However, remember that the system administrator (root) can still access them, regardless of set file permissions. Therefore, besides locking down file permissions, it is highly advisable that you encrypt the files using strong encryption software (try gpg encryption via programs like KGpg, or see ccrypt - symmetric cryptography). Group file sharing scenarios and the limits of basic UNIX permissions
Access Control Lists in Linux
# if you are not logged on as root, use 'su' first
apt-get install acl
Once you have installed setfacl --modify user:demo:5 testfile
mount -o remount,acl /
getfacl testfile
setfacl -R -m user:josh:6 filedir # sets read-write permissions for josh on filedir and all its contents
setfacl -m group:junior-sys-admins:4 /var/log/apache2/error.log # let group members of junior-sys-admins read Apache2 error log file
setfacl -m user:evilcraig:0 my_notes.txt # prevent user evilcraig from accessing my_notes.txt
Default (inherited) ACL
mkdir common_workspace
setfacl -m u:bob:7 common_workspace
setfacl -d -m u:bob:7 common_workspace
setfacl -m u:fred:7 common_workspace
setfacl -d -m u:fred:7 common_workspace
Appendix: Some hints
adduser me otherguy # adds user 'me' to group 'otherguy'
acl option. It allows for easy, graphical management of extended access rights, similar to that of Microsoft Windows.