Difference between revisions of "File permissions"

(Created page with "== chmod == You can change file permissions with: <console>$ chmod [r][g][u] [file]</console> [r] = number for root permissions, [g] = number for group permissions and [u] = n...")
 
m (Added link to ACL)
 
(15 intermediate revisions by 5 users not shown)
Line 1: Line 1:
== chmod ==
+
== File permissions ==
You can change file permissions with:
+
 
<console>$ chmod [r][g][u] [file]</console>
+
=== Common permissions ===
[r] = number for root permissions, [g] = number for group permissions and [u] = number for user permissions.
+
 
 +
With Linux, the most common way to handle user rights provides three distinct rights on files. The meaning of these rights for directories (which '''are''' files in Linux) is slightly different.
 +
 
 +
{|class="table table-striped"
 +
! Subject                  || Right (Oct. repr.) || Description        || Typical granted commands
 +
|-
 +
|rowspan=3| '''File'''      || <code>r (4)</code> || Read                || cat ''f'', less ''f'', grep ''f'', file ''f''
 +
|-
 +
                            || <code>w (2)</code> || Write              || sed -i ''f'', shred ''f'', truncate ''f'', vi ''f''
 +
|-
 +
                            || <code>x (1)</code> || Execution          || /absolute/path/to/''f'', relative/path/to/''f''
 +
|-
 +
|rowspan=3| '''Directory''' || <code>r (4)</code> || List contents      || ls ''d''
 +
|-
 +
                            || <code>w (2)</code> || Create/Remove files || touch ''d''/a_file, mkdir ''d''/a_dir, rm ''d''/a_file, rmdir ''d''/a_dir, chmod ''d''/a_file, chown ''d''/a_dir
 +
|-
 +
                            || <code>x (1)</code> || Browse hierarchy    || cd ''d'', pushd ''d''
 +
|}
 +
 
 +
You would notice that rights octal representation is coded with powers of 2. This is a common way to represent bunch two-states settings that can be independently toggled. Indeed, a file does not properly ''have'' a list of permissions set, you should see this rather as a a bit string (where a '''1''' at the position '''i''' means '''ON''' and a '''0''' means '''OFF''' for the right coded '''2<sup>i</sup>''').
 +
 
 +
An example is worth 1000 words:
 +
 
 +
<pre>
 +
rwx    Octal    Permissions
 +
000      0      None
 +
001      1      Execution only
 +
010      2      Read only
 +
100      4      Write only
 +
111      7      All (ie. Read and Write and Execution)
 +
110      6      All but Execution (ie. Read and Write)
 +
</pre>
 +
 
 +
File permissions are split into three categories of users:
 +
 
 +
; The owner of the file (<code>u</code> as user): Typically the creator of the file
 +
; The group of the file (<code>g</code> as group): Typically the main group of the owner
 +
; The others (<code>o</code> as others): Anybody else
 +
 
 +
File permissions are thus represented with nine bits. The three most significant representing the owner rights and the three least significant representing others rights. For instance, a typical file permission is <code>640</code> which means <q style="font-style:italic">The owner can read an write, the group have a read-only access, and other can't even read it</q>.
 +
 
 +
=== Alter permissions meaning ===
 +
 
 +
There is actually three more bits that allow you to alter the meaning of other permissions
 +
 
 +
{|class="table table-striped"
 +
! Subject                  || Right (Oct.&nbsp;repr.)  || Name      || Description
 +
|-
 +
|rowspan=3| '''File'''      || <code>s/S (4)</code> || Setuid&nbsp;bit || Enables to execute the underlying file in the name of the owner. This means that if you are allowed to execute this file (ie. have <code>x</code> right) and the file is owned by <code>simon</code>, it will be executed as if you were <code>simon</code> (namely, with his rights). A typical file using <code>setuid</code> is <code>/usr/bin/sudo</code>.
 +
|-
 +
                            || <code>s/S (2)</code> || Setgid&nbsp;bit || Same as the setuid bit but granting group permissions instead of owner's ones.
 +
|-
 +
                            || <code>t/T (1)</code> || Sticky&nbsp;bit || Prevent the underlying file to be flushed from memory after execution. Quite limited interest nowadays though.
 +
|-
 +
|rowspan=3| '''Directory''' || <code>s/S (4)</code> || Setuid&nbsp;bit || <i>No effect</i>
 +
|-
 +
                            || <code>s/S (2)</code> || Setgid&nbsp;bit || Causes any later file or sub-directory created within this directory to have the same group as the underlying directory instead of the creator's group by default. Moreover, later sub-directories would inherit the setgid bit.
 +
|-
 +
                            || <code>t/T (1)</code> || Sticky&nbsp;bit || Denies any user but the directory owner to remove a file from this directory. Of course, note that this does not prevent any user with write privilege on a file to truncate it.
 +
|}
 +
 
 +
The notation of the setuid bit (s/S), the setgit bit (s/S) and the sticky bit (t/T) overwrites the notation of the execution permission (x) of respectively the owner, the group and the others. Lowercase means <code>x</code> is set. Uppercase means <code>x</code> is not set.
 +
 
 +
For instance, in this sample, <code>-rws--x--T</code> is equivalent to the following octal value <code>5710</code> (where 5 means setuid+sticky).
 +
 
 +
=== Going further ===
 +
 
 +
As you would have notice, this does not provide a fine-grained way to manage permissions, but this is quite light, simple, and sufficient for most usages. However, if you think you need a really fine-grained level, you should consider looking at [[Access_Control_List]] or [[SELinux]].
 +
 
 +
== Manage user and groups ==
 +
 
 +
Users, and Groups  are named, and numbered.  the lower the number the more permissions the account has.  For example root user has the number 0, and root group has the number 0.  To display this information:
 +
<console>###i## cat /etc/passwd
 +
###i## cat /etc/group</console>
 +
 
 +
=== Add user ===
 +
 
 +
You can add user with useradd.
 +
 
 +
<console>
 +
###i## useradd -g users -G wheel,portage,audio,video,usb,cdrom,tty -m <username>
 +
</console>
 +
 
 +
=== Delete user ===
 +
 
 +
You can delete user with userdel.
 +
 
 +
<console>
 +
###i## userdel <username>
 +
</console>
 +
 
 +
{{fancynote|If you want to remove user files as well (home directory and mail spool, use the <code>-r</code> option:
 +
<console>
 +
###i## userdel -r <username>
 +
</console>
 +
}}
 +
 
 +
=== List groups ===
 +
 
 +
You can list groups with group.
 +
 
 +
<console>
 +
$##i## groups
 +
$##i## groups <username>
 +
</console>
 +
 
 +
=== Add or remove user from group ===
 +
 
 +
You can add or remove user from group with gpasswd.
 +
 
 +
<console>
 +
###i## gpasswd -a <user> <group>
 +
###i## gpasswd -d <user> <group>
 +
</console>
 +
 
 +
=== Create or delete groups ===
 +
 
 +
You can create or delete groups with groupadd.
 +
 
 +
<console>
 +
###i## groupadd <group>
 +
###i## groupdel <group>
 +
</console>
 +
 
 +
== Manage rights on files ==
 +
 
 +
=== Change file permissions ===
 +
 
 +
You can change file permissions with <code>chmod</code>.
 +
 
 +
<console>
 +
$##i## chmod <u><g><o> <file>
 +
</console>
 +
 
 +
Where <nowiki><u>, <g> and <o></nowiki> are respectively the octal representation of the rights you want to set for the owner, the group and others.
 +
 
 
<pre>7 = 4+2+1 (read/write/execute)
 
<pre>7 = 4+2+1 (read/write/execute)
 
6 = 4+2 (read/write)
 
6 = 4+2 (read/write)
Line 11: Line 146:
 
1 = 1 (execute)</pre>
 
1 = 1 (execute)</pre>
  
== chown ==
+
=== Change owner and group of file ===
You can change owner and group of file with:
+
 
<console># chown [user]:[group] [file]</console>
+
You can change owner and group of a file with <code>chown</code>.
You can change owner of folder and files inside recursively with:
+
 
<console># chown -R [user]:[group] [folder]</console>
+
<console>
 +
###i## chown <user>:<group> <file>
 +
</console>
 +
 
 +
You can change owner of a directory and children recursively with:
 +
 
 +
<console>
 +
###i## chown -R <user>:<group> <folder>
 +
</console>
 +
 
 +
=== Security ===
 +
 
 +
Generally you will want to have restrictive yet functional permissions.  777 on everything is a bad idea, especially files containing plain text passwords.  600 is common for files like this, with a high level user.  mediawiki's LocalSettings.php has database passwords.  A good method to lock this down is to change its permissions to 600, and set the file owner as the webserver's user.
 +
 
 +
=== Can I have write permission on a file while not being allowed to read it? ===
  
== gpasswd ==
+
Yes, you can! Example:
You can add user to group with:
+
<console># gpasswd -a [user] [group]</console>
+
You can remove user from group with:
+
<console># gpasswd -d [user] [group]</console>
+
  
== useradd ==
+
<console>
You can add new user with:
+
##i### echo "$USER: You can't read! >:)" > /tmp/test
<console># useradd -g users -G wheel,audio,portage -m [user]
+
##i### ls -l /tmp/test
# passwd [user]</console>
+
-rw-r--r-- 1 root root 6 Oct  2 07:30 /tmp/test
You can delete user with:
+
##i### chmod o-r+w /tmp/test
<console># userdel [user]</console>
+
##i### ls -l /tmp/test
 +
-rw-r---w- 1 root root 6 Oct  2 07:30 /tmp/test
 +
##i### cat /tmp/test
 +
root: You can't read! >:)
 +
##i### su anyuser
 +
##i##$ cat /tmp/test/
 +
cat: /tmp/test: Permission denied
 +
##i##$ vi /tmp/test/
 +
---[Permission Denied]---
 +
##i##$ echo "$USER: But I can write! :)" >> /tmp/test
 +
##i##$ exit
 +
##i### cat /tmp/test
 +
root: You can't read! >:)
 +
anyuser: But I can write! :)
 +
</console>
  
== groupadd ==
+
I don't know if this has an actual application though. Maybe if you need to allow some users to write (and truncate) logs in the same file but you don't want them to be able read what others wrote...
You can add new group with:
+
<console># groupadd [group]</console>
+
You can delete group with:
+
<console># groupdel [group]</console>
+
  
 
[[Category:HOWTO]]
 
[[Category:HOWTO]]
 +
[[Category:First Steps]]

Latest revision as of 16:40, October 4, 2014

File permissions

Common permissions

With Linux, the most common way to handle user rights provides three distinct rights on files. The meaning of these rights for directories (which are files in Linux) is slightly different.

Subject Right (Oct. repr.) Description Typical granted commands
File r (4) Read cat f, less f, grep f, file f
w (2) Write sed -i f, shred f, truncate f, vi f
x (1) Execution /absolute/path/to/f, relative/path/to/f
Directory r (4) List contents ls d
w (2) Create/Remove files touch d/a_file, mkdir d/a_dir, rm d/a_file, rmdir d/a_dir, chmod d/a_file, chown d/a_dir
x (1) Browse hierarchy cd d, pushd d

You would notice that rights octal representation is coded with powers of 2. This is a common way to represent bunch two-states settings that can be independently toggled. Indeed, a file does not properly have a list of permissions set, you should see this rather as a a bit string (where a 1 at the position i means ON and a 0 means OFF for the right coded 2i).

An example is worth 1000 words:

rwx    Octal    Permissions
000      0      None
001      1      Execution only
010      2      Read only
100      4      Write only
111      7      All (ie. Read and Write and Execution)
110      6      All but Execution (ie. Read and Write)

File permissions are split into three categories of users:

The owner of the file (u as user)
Typically the creator of the file
The group of the file (g as group)
Typically the main group of the owner
The others (o as others)
Anybody else

File permissions are thus represented with nine bits. The three most significant representing the owner rights and the three least significant representing others rights. For instance, a typical file permission is 640 which means The owner can read an write, the group have a read-only access, and other can't even read it.

Alter permissions meaning

There is actually three more bits that allow you to alter the meaning of other permissions

Subject Right (Oct. repr.) Name Description
File s/S (4) Setuid bit Enables to execute the underlying file in the name of the owner. This means that if you are allowed to execute this file (ie. have x right) and the file is owned by simon, it will be executed as if you were simon (namely, with his rights). A typical file using setuid is /usr/bin/sudo.
s/S (2) Setgid bit Same as the setuid bit but granting group permissions instead of owner's ones.
t/T (1) Sticky bit Prevent the underlying file to be flushed from memory after execution. Quite limited interest nowadays though.
Directory s/S (4) Setuid bit No effect
s/S (2) Setgid bit Causes any later file or sub-directory created within this directory to have the same group as the underlying directory instead of the creator's group by default. Moreover, later sub-directories would inherit the setgid bit.
t/T (1) Sticky bit Denies any user but the directory owner to remove a file from this directory. Of course, note that this does not prevent any user with write privilege on a file to truncate it.

The notation of the setuid bit (s/S), the setgit bit (s/S) and the sticky bit (t/T) overwrites the notation of the execution permission (x) of respectively the owner, the group and the others. Lowercase means x is set. Uppercase means x is not set.

For instance, in this sample, -rws--x--T is equivalent to the following octal value 5710 (where 5 means setuid+sticky).

Going further

As you would have notice, this does not provide a fine-grained way to manage permissions, but this is quite light, simple, and sufficient for most usages. However, if you think you need a really fine-grained level, you should consider looking at Access_Control_List or SELinux.

Manage user and groups

Users, and Groups are named, and numbered. the lower the number the more permissions the account has. For example root user has the number 0, and root group has the number 0. To display this information:

# cat /etc/passwd
# cat /etc/group

Add user

You can add user with useradd.

# useradd -g users -G wheel,portage,audio,video,usb,cdrom,tty -m <username>

Delete user

You can delete user with userdel.

# userdel <username>

Note

If you want to remove user files as well (home directory and mail spool, use the -r option:

# userdel -r <username>

List groups

You can list groups with group.

$ groups
$ groups <username>

Add or remove user from group

You can add or remove user from group with gpasswd.

# gpasswd -a <user> <group>
# gpasswd -d <user> <group>

Create or delete groups

You can create or delete groups with groupadd.

# groupadd <group>
# groupdel <group>

Manage rights on files

Change file permissions

You can change file permissions with chmod.

$ chmod <u><g><o> <file>

Where <u>, <g> and <o> are respectively the octal representation of the rights you want to set for the owner, the group and others.

7 = 4+2+1 (read/write/execute)
6 = 4+2 (read/write)
5 = 4+1 (read/execute)
4 = 4 (read)
3 = 2+1 (write/execute)
2 = 2 (write)
1 = 1 (execute)

Change owner and group of file

You can change owner and group of a file with chown.

# chown <user>:<group> <file>

You can change owner of a directory and children recursively with:

# chown -R <user>:<group> <folder>

Security

Generally you will want to have restrictive yet functional permissions. 777 on everything is a bad idea, especially files containing plain text passwords. 600 is common for files like this, with a high level user. mediawiki's LocalSettings.php has database passwords. A good method to lock this down is to change its permissions to 600, and set the file owner as the webserver's user.

Can I have write permission on a file while not being allowed to read it?

Yes, you can! Example:

# echo "$USER: You can't read! >:)" > /tmp/test
# ls -l /tmp/test
-rw-r--r-- 1 root root 6 Oct  2 07:30 /tmp/test
# chmod o-r+w /tmp/test
# ls -l /tmp/test
-rw-r---w- 1 root root 6 Oct  2 07:30 /tmp/test
# cat /tmp/test
root: You can't read! >:)
# su anyuser
$ cat /tmp/test/
cat: /tmp/test: Permission denied
$ vi /tmp/test/
---[Permission Denied]---
$ echo "$USER: But I can write! :)" >> /tmp/test
$ exit
# cat /tmp/test
root: You can't read! >:)
anyuser: But I can write! :)

I don't know if this has an actual application though. Maybe if you need to allow some users to write (and truncate) logs in the same file but you don't want them to be able read what others wrote...