Linux Permissions Basics

Lin­ux Serv­er

Lin­ux Desk­top

The con­tent of this ar­ti­cle is based or tak­en from the Cisco's Net­work­ing Acad­e­my NDG Lin­ux Es­sen­tials, Chap­ter 17 – Own­er­ship and Per­mis­sions and Chap­ter 18 – Spe­cial Di­rec­to­ries and Files.

Per­mis­sions

The out­put of the ls ‑l com­mand dis­plays ten char­ac­ters at the be­gin­ning of each line. These char­ac­ters in­di­cate the type of file and the per­mis­sions of the file. For ex­am­ple, con­sid­er the out­put of the fol­low­ing com­mand:

ls -l /etc/passwd

-rw-r--r--. 1 root root 4135 May 27 21:08 /etc/passwd

The stat com­mand dis­plays more de­tailed in­for­ma­tion about a file, in­clud­ing pro­vid­ing the group own­er­ship both by group name and GID num­ber:

stat /etc/passwd

  File: /etc/passwd
  Size: 1835            Blocks: 8          IO Block: 4096   regular file
Device: fd01h/64769d    Inode: 3016073     Links: 1
Access: (0644/-rw-r--r--)  Uid: (    0/    root)   Gid: (    0/    root)
Access: 2022-06-04 11:15:14.749541612 +0300
Modify: 2022-03-13 10:11:44.222373720 +0200
Change: 2022-03-13 10:11:44.222373720 +0200
 Birth: 2022-03-13 10:11:44.222373720 +0200

File Type

The first char­ac­ter of each line in­di­cates the type of file:

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

The fol­low­ing ta­ble de­scribes the pos­si­ble val­ues for the file type:

Character	Type of the File
-	A reg­u­lar file, which may be emp­ty, or con­tain text or bi­na­ry da­ta.
d	A di­rec­to­ry file, which con­tains the names of oth­er files and links to them.
l	A sym­bol­ic link is a file name that refers (points) to an­oth­er file.
b	A block file is one that re­lates to a block hard­ware de­vice where da­ta is read in blocks of da­ta.
c	A char­ac­ter file is one that re­lates to a char­ac­ter hard­ware de­vice where da­ta is read one byte at a time.
p	A pipe file works sim­i­lar to the pipe sym­bol, al­low­ing for the out­put of one process to com­mu­ni­cate to an­oth­er process through the pipe file, where the out­put of the one process is used as in­put for the oth­er process.
s	A sock­et file al­lows two process­es to com­mu­ni­cate, where both process­es are al­lowed to ei­ther send or re­ceive da­ta.

Con­sid­er This: Al­though all the file types are list­ed in the ta­ble above, typ­i­cal­ly you don’t en­counter any­thing but reg­u­lar, di­rec­to­ry and link files un­less you ex­plore the /​​​dev di­rec­to­ry.

Per­mis­sion Groups

The next nine char­ac­ters demon­strate the per­mis­sions of the file.

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

The per­mis­sions set on these files de­ter­mine the lev­el of ac­cess that a user has on the file. When a user runs a pro­gram and the pro­gram ac­cess­es a file, then the per­mis­sions are checked to de­ter­mine whether the user has the cor­rect ac­cess rights to the file.

The per­mis­sions are grouped in­to three dif­fer­ent roles, rep­re­sent­ing the dif­fer­ent users that may try to ac­cess the file.

If you aren't the own­er and you're not a mem­ber of the file/​​​directory group, then your per­mis­sions would be oth­ers.

User Own­er

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Char­ac­ters 2–4 in­di­cate the per­mis­sions for the user that owns the file. If you are the own­er of the file, then on­ly the user own­er per­mis­sions are used to de­ter­mine ac­cess to that file.

Group Own­er

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Char­ac­ters 5–7 in­di­cate the per­mis­sions for the group that owns the file. If you are not the own­er but are a mem­ber of the group that owns the file, then on­ly group own­er per­mis­sions are used to de­ter­mine ac­cess to that file.

Oth­er Per­mis­sions

-rw-r--r-- 1 root root 4135 May 27 21:08 /etc/passwd

Char­ac­ters 8–10 in­di­cate the per­mis­sions for oth­ers or what is some­times re­ferred to as the world's per­mis­sions. This group in­cludes all users who are not the file own­er or a mem­ber of the file's group.

Per­mis­sion Types

Each group is at­trib­uted three ba­sic types of per­mis­sions: read, write, and ex­e­cute.

User Own­er	Group Own­er	Oth­er
Read Write Ex­e­cute r w x	Read Write Ex­e­cute r w x	Read Write Ex­e­cute r w x

The per­mis­sions them­selves are de­cep­tive­ly sim­ple and have a dif­fer­ent mean­ing de­pend­ing on whether they are ap­plied to a file or a di­rec­to­ry.

Read

The first char­ac­ter of each group rep­re­sents the read per­mis­sion. There is an r char­ac­ter if the group has the read per­mis­sion, or a - char­ac­ter if the group does not.

• On a file, this al­lows process­es to read the con­tents of the file, mean­ing the con­tents can be viewed and copied.
• On a di­rec­to­ry, file names in the di­rec­to­ry can be list­ed, but oth­er de­tails are not avail­able.

Write

The sec­ond char­ac­ter of each group rep­re­sents the write per­mis­sion. There is a w char­ac­ter if the group has the write per­mis­sion, or a - char­ac­ter if the group does not.

• A file can be writ­ten to by the process, so changes to a file can be saved. Note that w per­mis­sion re­al­ly re­quires r per­mis­sion on the file to work cor­rect­ly.
• On a di­rec­to­ry, files can be added to or re­moved from the di­rec­to­ry. Note that w per­mis­sion re­quires x per­mis­sion on the di­rec­to­ry to work cor­rect­ly.

Ex­e­cute

The third char­ac­ter of each group rep­re­sents the ex­e­cute per­mis­sion. There is an x char­ac­ter if the group has the ex­e­cute per­mis­sion, or a - char­ac­ter if the group does not.

• A file can be ex­e­cut­ed or run as a process.
• On a di­rec­to­ry, the user can use the cd com­mand to "get in­to" the di­rec­to­ry and use the di­rec­to­ry in a path­name to ac­cess files and, po­ten­tial­ly, sub­di­rec­to­ries un­der this.

Sym­bol­ic Method

If you want to mod­i­fy some of the cur­rent per­mis­sions, the sym­bol­ic method is usu­al­ly eas­i­er to use. With this method, you spec­i­fy which per­mis­sions you want to change on the file, and the oth­er per­mis­sions re­main as they are.

When spec­i­fy­ing the new_​​​permission ar­gu­ment of the chmod com­mand us­ing the sym­bol­ic method three types of in­for­ma­tion are re­quired.

Start by us­ing one or more of the fol­low­ing char­ac­ters to in­di­cate which per­mis­sion group(s) to ap­ply the changes to:

u	user own­er
g	group own­er
o	oth­ers
a	all (user own­er, group own­er, and oth­ers)

‌⁠​​⁠Then choose one of the fol­low­ing op­er­a­tors to in­di­cate how to mod­i­fy the per­mis­sions:

+	add
-	re­move
=	equals

Last­ly, use the fol­low­ing char­ac­ters to spec­i­fy the per­mis­sions type(s) to change:

r	read
w	write
x	ex­e­cute

For ex­am­ple, to give the group own­er write per­mis­sion on a file named abc.txt, you could use the fol­low­ing com­mand:

chmod g+w abc.txt
ls -l abc.txt

-rw-rw-r-- 1 root root 0 Dec 19 18:58 abc.txt

On­ly the group owner's per­mis­sion was changed. All oth­er per­mis­sions re­mained as they were pri­or to the ex­e­cu­tion of the chmod com­mand.

You can com­bine val­ues to make mul­ti­ple changes to the file's per­mis­sions. For ex­am­ple, con­sid­er the fol­low­ing com­mand which adds the ex­e­cute per­mis­sion to the user own­er and group own­er and re­moves the read per­mis­sion for oth­ers:

chmod ug+x,o-r abc.txt
ls -l abc.txt

-rwxrwx--- 1 root root 0 Dec 19 18:58 abc.txt

Last­ly, you could use the = char­ac­ter, which adds spec­i­fied per­mis­sions and caus­es un­men­tioned ones to be re­moved. For ex­am­ple, to give the user own­er on­ly read and ex­e­cute per­mis­sions, re­mov­ing the write per­mis­sion:

chmod u=rx abc.txt
ls -l abc.txt

-r-xrwx--- 1 root root 0 Dec 19 18:58 abc.txt

More ex­am­ples:

chmod a+x file	Gives every­one ex­e­cute per­mis­sion
chmod g‑w file	Re­moves write per­mis­sion for group own­ers
chmod go+r file	Adds read per­mis­sion for group own­er and oth­ers
chmod o=rwx	Sets oth­ers per­mis­sions to read, write and ex­e­cute

Nu­mer­ic Method

The nu­mer­ic method (al­so called the oc­tal method) is use­ful when chang­ing many per­mis­sions on a file. It is based on the oc­tal num­ber­ing sys­tem in which each per­mis­sion type is as­signed a nu­mer­ic val­ue:

4	Read
2	Write
1	Ex­e­cute

By us­ing a com­bi­na­tion of num­bers from 0 to 7, any pos­si­ble com­bi­na­tion of read, write and ex­e­cute per­mis­sions can be spec­i­fied for a sin­gle per­mis­sion group set. For ex­am­ple:

7	rwx
6	rw-
5	r‑x
4	r–
3	-wx
2	-w-
1	–x
0	—

The new_​​​permission ar­gu­ment is spec­i­fied as three num­bers, one num­ber for each per­mis­sion group. When the nu­mer­ic method is used to change per­mis­sions, all nine per­mis­sions must be spec­i­fied. Be­cause of this, the sym­bol­ic method is gen­er­al­ly eas­i­er for chang­ing a few per­mis­sions while the nu­mer­ic method is bet­ter for changes that are more dras­tic.

For ex­am­ple, to set the per­mis­sions of a file named abc.txt to be rwxr-xr– you could use the fol­low­ing com­mand:

chmod 754 abc.txt
ls -l abc.txt

-rwxr-xr-- 1 root root 0 Dec 19 18:58 abc.txt

---

To use the chmod com­mand with oc­tal no­ta­tion, you must first un­der­stand the oc­tal val­ue of the per­mis­sions:

Read r	4
Write w	2
Ex­e­cute x	1

From the last list­ing of the abc.txt file, the per­mis­sions were shown to be rwx for the user own­er, r‑x for the group own­er, and r– for oth­ers. To ex­press these per­mis­sions in oc­tal no­ta­tion, a to­tal is cal­cu­lat­ed for each own­er­ship.

As a re­sult, the user's per­mis­sion to­tal would be cal­cu­lat­ed as 4 + 2 + 1, or 7, where 4 is for the read, 2 is for the write, and 1 is for the ex­e­cute per­mis­sion.

The group's per­mis­sion to­tal would be 4 + 1 or 5, where 4 is for the read per­mis­sion, and 1 is for the ex­e­cute per­mis­sion.

The oth­ers' own­er­ship per­mis­sion would sim­ply be 4 for the read per­mis­sion that they have.

Putting it all to­geth­er, the oc­tal val­ue for the cur­rent per­mis­sions would be 754.

De­fault Per­mis­sions

The umask com­mand is a fea­ture that is used to de­ter­mine de­fault per­mis­sions that are set when a file or di­rec­to­ry is cre­at­ed. De­fault per­mis­sions are de­ter­mined when the umask val­ue is sub­tract­ed from the max­i­mum al­low­able de­fault per­mis­sions. The max­i­mum de­fault per­mis­sions are dif­fer­ent for files and di­rec­to­ries:

file	rw-rw-rw-
di­rec­to­ries	rwxr­wxr­wx

The per­mis­sions that are ini­tial­ly set on a file when it is cre­at­ed can­not ex­ceed rw-rw-rw-. To have the ex­e­cute per­mis­sion set on a file, you first need to cre­ate the file and then change the per­mis­sions.

The umask com­mand can be used to dis­play the cur­rent umask val­ue:

umask

0002

A break­down of the out­put:

A break­down of the out­put:

• The first 0 in­di­cates that the umask is giv­en as an oc­tal num­ber.
• The sec­ond 0 in­di­cates which per­mis­sions to sub­tract from the de­fault user owner's per­mis­sions.
• The third 0 in­di­cates which per­mis­sions to sub­tract from the de­fault group owner's per­mis­sions.
• The last num­ber 2 in­di­cates which per­mis­sions to sub­tract from the de­fault other's per­mis­sions.

Note that dif­fer­ent users may have dif­fer­ent umasks. Typ­i­cal­ly the root user has a more re­stric­tive umask than nor­mal user ac­counts:

umask

0022

To un­der­stand how umask works, as­sume that the umask of a file is set to 027 and con­sid­er the fol­low­ing:

File De­fault	666
Umask	-027
Re­sult	640

The 027 umask means that new files would re­ceive 640 or rw‑r—– per­mis­sions by de­fault, as demon­strat­ed be­low:

umask 027
touch sample 
ls -l sample

-rw-r-----. 1 sysadmin sysadmin 0 Oct 28 20:14 sample

Be­cause the de­fault per­mis­sions for di­rec­to­ries are dif­fer­ent than for files, a umask of 027 would re­sult in dif­fer­ent ini­tial per­mis­sions on new di­rec­to­ries:

Di­rec­to­ry De­fault	777
Umask	-027
Re­sult	750

The 027 umask means that di­rec­to­ries files would re­ceive 750 or rwxr‑x— per­mis­sions by de­fault, as demon­strat­ed be­low:

umask 027
mkdir test-dir
ls -ld test-dir

drwxr-x---. 1 sysadmin sysadmin 4096 Oct 28 20:25 test-dir

The new umask is on­ly ap­plied to file and di­rec­to­ries cre­at­ed dur­ing that ses­sion. When a new shell is start­ed, the de­fault umask will again be in ef­fect.

Per­ma­nent­ly chang­ing a user's umask re­quires mod­i­fy­ing the .bashrc file lo­cat­ed in that user's home di­rec­to­ry.

Se­tu­id

When the se­tu­id per­mis­sion is set on an ex­e­cutable bi­na­ry file (a pro­gram) the bi­na­ry file is run as the own­er of the file, not as the user who ex­e­cut­ed it. This per­mis­sion is set on a hand­ful of sys­tem util­i­ties so that they can be run by nor­mal users, but ex­e­cut­ed with the per­mis­sions of root, pro­vid­ing ac­cess to sys­tem files that the nor­mal user doesn't nor­mal­ly have ac­cess to.

Con­sid­er the fol­low­ing sce­nario in which the user sysad­min at­tempts to view the con­tents of the /​​​etc/​​​shadow file:

more /etc/shadow

/etc/shadow: Permission denied

ls -l /etc/shadow

-rw-r-----. 1 root root 5195 Oct 21 19:57 /etc/shadow

The per­mis­sions on /​​​etc/​​​shadow do not al­low nor­mal users to view (or mod­i­fy) the file. Since the file is owned by the root user, the ad­min­is­tra­tor can tem­porar­i­ly mod­i­fy the per­mis­sions to view or mod­i­fy this file.

Now con­sid­er the pass­wd com­mand. When this com­mand runs, it mod­i­fies the /​​​etc/​​​shadow file, which seems im­pos­si­ble be­cause oth­er com­mands that the sysad­min user runs that try to ac­cess this file fail. So, why can the sysad­min user mod­i­fy the /​​​etc/​​​shadow file while run­ning the pass­wd com­mand when nor­mal­ly this user has no ac­cess to the file?

The pass­wd com­mand has the spe­cial se­tu­id per­mis­sion set. When the pass­wd com­mand is run, and the com­mand ac­cess­es the /​​​etc/​​​shadow file, the sys­tem acts as if the user ac­cess­ing the file is the own­er of the pass­wd com­mand (the root user), not the user who is run­ning the com­mand.

You can see this per­mis­sion set by run­ning the ls ‑l com­mand:

ls -l /usr/bin/passwd

-rwsr-xr-x 1 root root 31768 Jan 28 2010 /usr/bin/passwd

No­tice the out­put of the ls com­mand above; the se­tu­id per­mis­sion is rep­re­sent­ed by the s in the own­er per­mis­sions where the ex­e­cute per­mis­sion would nor­mal­ly be rep­re­sent­ed. A low­er­case s means that both the se­tu­id and ex­e­cute per­mis­sion are set, while an up­per­case S means that on­ly se­tu­id and not the user ex­e­cute per­mis­sion is set.

Like the read, write and ex­e­cute per­mis­sions, spe­cial per­mis­sions can be set with the chmod com­mand, us­ing ei­ther the sym­bol­ic and oc­tal meth­ods.

To add the se­tu­id per­mis­sion sym­bol­i­cal­ly, run:

chmod u+s file

To add the se­tu­id per­mis­sion nu­mer­i­cal­ly, add 4000 to the file's ex­ist­ing per­mis­sions (as­sume the file orig­i­nal­ly had 775 for its per­mis­sion in the fol­low­ing ex­am­ple):

chmod 4775 file

To re­move the se­tu­id per­mis­sion sym­bol­i­cal­ly, run:

chmod u-s file

To re­move the se­tu­id per­mis­sion nu­mer­i­cal­ly, sub­tract 4000 from the file's ex­ist­ing per­mis­sions:

chmod 0775 file

Pre­vi­ous­ly, we set per­mis­sion with the oc­tal method us­ing three-dig­it codes. When a three-dig­it code is pro­vid­ed, the chmod com­mand as­sumes that the first dig­it be­fore the three-dig­it code is 0. On­ly when four dig­its are spec­i­fied is a spe­cial per­mis­sion set.

If three dig­its are spec­i­fied when chang­ing the per­mis­sion on a file that al­ready has a spe­cial per­mis­sion set, the first dig­it will be set to 0, and the spe­cial per­mis­sion will be re­moved from the file.

Set­gid

The set­gid per­mis­sion is sim­i­lar to se­tu­id, but it makes use of the group own­er per­mis­sions. There are two forms of set­gid per­mis­sions: set­gid on a file and set­gid on a di­rec­to­ry. The be­hav­ior of set­gid de­pends on whether it is set on a file or di­rec­to­ry.

Set­gid on Files

The set­gid per­mis­sion on a file is very sim­i­lar to se­tu­id; it al­lows a user to run an ex­e­cutable bi­na­ry file in a man­ner that pro­vides them ad­di­tion­al (tem­po­rary) group ac­cess. The sys­tem al­lows the user run­ning the com­mand to ef­fec­tive­ly be­long to the group that owns the file, but on­ly in the set­gid pro­gram.

A good ex­am­ple of the set­gid per­mis­sion on an ex­e­cutable file is the /​​​usr/​​​bin/​​​wall com­mand. No­tice the per­mis­sions for this file as well as the group own­er:

ls -l /usr/bin/wall

-rwxr-sr-x 1 root tty 30800 May 16 2018 /usr/bin/wall

You can see that this file is set­gid by the pres­ence of the s in the group's ex­e­cute po­si­tion. Due to this ex­e­cutable be­ing owned by the tty group, when a user ex­e­cutes this com­mand, the com­mand is able to ac­cess files that are group owned by the tty group.

This ac­cess is im­por­tant be­cause the /​​​usr/​​​bin/​​​wall com­mand sends mes­sages to ter­mi­nals, which is ac­com­plished by writ­ing da­ta to files like the fol­low­ing:

ls -l /dev/tty?

crw--w----. 1 root tty 4, 0 Mar 29  2013 /dev/tty0 
crw--w----. 1 root tty 4, 1 Oct 21 19:57 /dev/tty1

Note that the tty group has write per­mis­sion on the files above while users who are not in the tty group ("oth­ers") have no per­mis­sions on these files. With­out the set­gid per­mis­sion, the /​​​usr/​​​bin/​​​wall com­mand would fail.

Set­gid on Di­rec­to­ries

When set on a di­rec­to­ry, the set­gid per­mis­sion caus­es files cre­at­ed in the di­rec­to­ry to be owned by the group that owns the di­rec­to­ry au­to­mat­i­cal­ly. This be­hav­ior is con­trary to how new file group own­er­ship would nor­mal­ly func­tion, as by de­fault new files are group owned by the pri­ma­ry group of the user who cre­at­ed the file.

In ad­di­tion, any di­rec­to­ries cre­at­ed with­in a di­rec­to­ry with the set­gid per­mis­sion set are not on­ly owned by the group that owns the set­gid di­rec­to­ry, but the new di­rec­to­ry au­to­mat­i­cal­ly has set­gid set on it as well. In oth­er words, if a di­rec­to­ry is set­gid, then any di­rec­to­ries cre­at­ed with­in that di­rec­to­ry in­her­it the set­gid per­mis­sion.

By de­fault when the ls com­mand is ex­e­cut­ed on a di­rec­to­ry, it out­puts in­for­ma­tion on the files con­tained with­in the di­rec­to­ry. To view in­for­ma­tion about the di­rec­to­ry it­self add the -d op­tion. Used with the -l op­tion, it can be used to de­ter­mine if the set­gid per­mis­sion is set. The fol­low­ing ex­am­ple shows that the /​​​tmp/​​​data di­rec­to­ry has the set­gid per­mis­sion set and that it is owned by the de­mo group.

ls -ld /tmp/data

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

In a long list­ing, the set­gid per­mis­sion is rep­re­sent­ed by an s in the group ex­e­cute po­si­tion. A low­er­case s means that both set­gid and group ex­e­cute per­mis­sions are set:

drwxrwsrwx. 2 root demo 4096 Oct 30 23:20 /tmp/data

An up­per­case S means that on­ly set­gid and not group ex­e­cute per­mis­sion is set. If you see an up­per­case S in the group ex­e­cute po­si­tion of the per­mis­sions, then it in­di­cates that al­though the set­gid per­mis­sion is set, it is not re­al­ly in ef­fect be­cause the group lacks the ex­e­cute per­mis­sion to use it:

drwxrwSr-x. 2 root root 5036 Oct 30 23:22 /tmp/data2

Typ­i­cal­ly files cre­at­ed by the user sysad­min are owned by their pri­ma­ry group, al­so called sysad­min.

id

uid=500(sysadmin) gid=500(sysadmin) 
groups=500(sysadmin),10001(research),10002(development) 
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023

How­ev­er, if the user sysad­min cre­ates a file in the /​​​tmp/​​​data di­rec­to­ry, the set­gid di­rec­to­ry from the pre­ced­ing ex­am­ple, the group own­er­ship of the file isn't the sysad­min group, but rather the group that owns the di­rec­to­ry de­mo:

touch /tmp/data/file.txt 
ls -ld /tmp/data/file.txt

-rw-rw-r--. 1 bob demo 0 Oct 30 23:21 /tmp/data/file.txt

Why would an ad­min­is­tra­tor want to set up a set­gid di­rec­to­ry? First, con­sid­er the fol­low­ing user ac­counts:

• The user bob is a mem­ber of the pay­roll group.
• The user sue is a mem­ber of the staff group.
• The user tim is a mem­ber of the ac­ct group.

In this sce­nario, these three users need to work on a joint project. They ap­proach the ad­min­is­tra­tor to ask for a shared di­rec­to­ry in which they can work to­geth­er, but that no one else can ac­cess their files. The ad­min­is­tra­tor does the fol­low­ing:

1. Cre­ates a new group called team.
2. Adds bob, sue, and tim to the team group.
3. Makes a new di­rec­to­ry called /​​​home/​​​team.
4. Makes the group own­er of the /​​​home/​​​team di­rec­to­ry be the team group.
5. Gives the /​​​home/​​​team di­rec­to­ry the fol­low­ing per­mis­sions: rwxr­wx—

As a re­sult, bob, sue, and tim can ac­cess the /​​​home/​​​team di­rec­to­ry and add files. How­ev­er, there is a po­ten­tial prob­lem: when bob cre­ates a file in the /​​​home/​​​team di­rec­to­ry, the new file is owned by his pri­ma­ry group:

-rw-r-----. 1 bob payroll 100 Oct 30 23:21 /home/team/file.txt

Un­for­tu­nate­ly, while sue and tim can ac­cess the /​​​home/​​​team di­rec­to­ry, they can't do any­thing with bob's file. Their per­mis­sions for that file are the oth­ers per­mis­sions (—).

If the ad­min­is­tra­tor sets the set­gid per­mis­sion to the /​​​home/​​​team di­rec­to­ry, then when bob cre­ates a file, it is owned the team group:

-rw-r-----. 1 bob team 100 Oct 30 23:21 /home/team/file.txt

As a re­sult, sue and tim would have ac­cess to the file through the group own­er per­mis­sions (r–).

Cer­tain­ly, bob could change the group own­er­ship or the oth­ers per­mis­sions af­ter cre­at­ing the file, but that would be­come te­dious if there were many new files be­ing cre­at­ed. The set­gid per­mis­sion makes it eas­i­er for this sit­u­a­tion.

Set­ting Set­gid

Use the fol­low­ing syn­tax to add the set­gid per­mis­sion sym­bol­i­cal­ly:

chmod g+s <file|directory>

To add the set­gid per­mis­sion nu­mer­i­cal­ly, add 2000 to the file's ex­ist­ing per­mis­sions (as­sume in the fol­low­ing ex­am­ple that the di­rec­to­ry orig­i­nal­ly had 775 for its per­mis­sions):

chmod 2775 <file|directory>

To re­move the set­gid per­mis­sion sym­bol­i­cal­ly, run:

chmod g-s <file|directory>

To re­move the set­gid per­mis­sion nu­mer­i­cal­ly, sub­tract 2000 from the file's ex­ist­ing per­mis­sions:

chmod 0775 <file|directory>

Sticky Bit

The sticky bit per­mis­sion is used to pre­vent oth­er users from delet­ing files that they do not own in a shared di­rec­to­ry. Re­call that any user with write per­mis­sion on a di­rec­to­ry can cre­ate files in that di­rec­to­ry, as well as delete any file in the di­rec­to­ry, even if they do not own the file!

The sticky bit per­mis­sion al­lows for files to be shared with oth­er users, by chang­ing write per­mis­sion on the di­rec­to­ry so that users can still add and delete files in the di­rec­to­ry, but files can on­ly be delet­ed by the own­er of the file or the root user.

A good ex­am­ple of the use of sticky bit di­rec­to­ries would be the /​​​tmp and /​​​var/​​​tmp di­rec­to­ries. These di­rec­to­ries are de­signed as lo­ca­tions where any user can cre­ate a tem­po­rary file.

Be­cause these di­rec­to­ries are in­tend­ed to be writable by all users, they are con­fig­ured to use the sticky bit. With­out this spe­cial per­mis­sion, users would be able to delete any files in this di­rec­to­ry, in­clud­ing those that be­long to oth­er users.

The out­put of the ls ‑l com­mand dis­plays the sticky bit by a t char­ac­ter in the ex­e­cute bit of the oth­ers per­mis­sion group:

ls -ld /tmp

drwxrwxrwt 1 root root 4096 Mar 14 2016 /tmp

A low­er­case t means that both the sticky bit and ex­e­cute per­mis­sions are set for oth­ers. An up­per­case T means that on­ly the sticky bit per­mis­sion is set.

While the cap­i­tal S in­di­cat­ed a prob­lem with the se­tu­id or set­gid per­mis­sions, a cap­i­tal T does not nec­es­sar­i­ly in­di­cate a prob­lem, as long as the group own­er still has the ex­e­cute per­mis­sion.

To set the sticky bit per­mis­sion sym­bol­i­cal­ly, ex­e­cute a com­mand like the fol­low­ing:

chmod o+t <directory>

To set the sticky bit per­mis­sion nu­mer­i­cal­ly, add 1000 to the directory's ex­ist­ing per­mis­sions (as­sume the di­rec­to­ry in the fol­low­ing ex­am­ple orig­i­nal­ly had 775 for its per­mis­sions):

chmod 1775 <file|directory>

To re­move the sticky per­mis­sion sym­bol­i­cal­ly, run:

chmod o-t <directory>

‌⁠​​⁠​To re­move the sticky bit per­mis­sion nu­mer­i­cal­ly, sub­tract 1000 from the directory's ex­ist­ing per­mis­sions:

chmod 0775 <directory>

Links

Each link­ing method, hard and sym­bol­ic (soft), re­sults in the same over­all ac­cess, but us­es dif­fer­ent tech­niques. There are pros and cons to each method, so know­ing both tech­niques and when to use them is im­por­tant.

Hard Links

To un­der­stand hard links, it is help­ful to un­der­stand a lit­tle bit about how the file sys­tem keeps track of files. For every file cre­at­ed, there is a block of da­ta on the file sys­tem that stores the meta­da­ta of the file. Meta­da­ta in­cludes in­for­ma­tion about the file like the per­mis­sions, own­er­ship, and time­stamps. Meta­da­ta does not in­clude the file name or the con­tents of the file, but it does in­clude just about all oth­er in­for­ma­tion about the file.

This meta­da­ta is called the file's in­ode ta­ble. The in­ode ta­ble al­so in­cludes point­ers to the oth­er blocks on the file sys­tem called da­ta blocks where the da­ta is stored.

Every file on a par­ti­tion has a unique iden­ti­fi­ca­tion num­ber called an in­ode num­ber. The ls ‑i com­mand dis­plays the in­ode num­ber of a file.

ls -i /tmp/file.txt

215220874 /tmp/file.txt

Like users and groups, what de­fines a file is not its name, but rather the num­ber it has been as­signed. The in­ode ta­ble does not in­clude the file name. For each file, there is al­so an en­try that is stored in a directory's da­ta area (da­ta block) that in­cludes an as­so­ci­a­tion be­tween an in­ode num­ber and a file name.

Like users and groups, what de­fines a file is not its name, but rather the num­ber it has been as­signed. The in­ode ta­ble does not in­clude the file name. For each file, there is al­so an en­try that is stored in a directory's da­ta area (da­ta block) that in­cludes an as­so­ci­a­tion be­tween an in­ode num­ber and a file name.

In the da­ta block for the /​​​etc di­rec­to­ry, there would be a list of all of the files in this di­rec­to­ry and their cor­re­spond­ing inode num­ber. For ex­am­ple:

File Name	In­ode Num­ber
pass­wd	123
shad­ow	175
group	144
gshad­ow	897

When you at­tempt to ac­cess the /​​​etc/​​​passwd file, the sys­tem us­es this ta­ble to trans­late the file name in­to an in­ode num­ber. It then re­trieves the file da­ta by look­ing at the in­for­ma­tion in the in­ode ta­ble for the file.

Hard links are two file names that point to the same in­ode. For ex­am­ple, con­sid­er the fol­low­ing di­rec­to­ry en­tries:

File Name	In­ode Num­ber
pass­wd	123
my­pass­wd	123
shad­ow	175
group	144
gshad­ow	897

Be­cause both the pass­wd and my­pass­wd file have the same in­ode num­ber, they es­sen­tial­ly are the same file. You can ac­cess the file da­ta us­ing ei­ther file name.

When you ex­e­cute the ls ‑li com­mand, the num­ber that ap­pears for each file be­tween the per­mis­sions and the user own­er is the link count num­ber:

echo data > file.original
ls -li file.*

278772 -rw-rw-r--. 1 sysadmin sysadmin 5 Oct 25 15:42 file.original

The link count num­ber in­di­cates how many hard links have been cre­at­ed. When the num­ber is a val­ue of one, then the file has on­ly one name linked to the in­ode. To cre­ate hard links, the ln com­mand is used with two ar­gu­ments. The first ar­gu­ment is an ex­ist­ing file name to link to, called a tar­get, and the sec­ond ar­gu­ment is the new file name to link to the tar­get.

ln <target> <link_name>

When the ln com­mand is used to cre­ate a hard link, the link count num­ber in­creas­es by one for each ad­di­tion­al file­name:

ln file.original file.hard.1
ls -li file.*

278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.hard.1 
278772 -rw-rw-r--. 2 sysadmin sysadmin 5 Oct 25 15:53 file.original

Im­por­tant: You can­not cre­ate hard links to di­rec­to­ries. Al­so, a hard link to a file must ex­ist with­in the same filesys­tem (par­ti­tion) as the file that it links to.

Sym­bol­ic Links

A sym­bol­ic link, al­so called a soft link, is sim­ply a file that points to an­oth­er file. There are sev­er­al sym­bol­ic links al­ready on the sys­tem, in­clud­ing sev­er­al in the /​​​etc di­rec­to­ry:

ls -l /etc/grub.conf

lrwxrwxrwx. 1 root root 22 Feb 15 2011 /etc/grub.conf -> ../boot/grub/grub.conf

In the pre­vi­ous ex­am­ple, the file /etc/grub.conf "points to" the ../boot/grub/grub.conf file. So, if you were to at­tempt to view the con­tents of the /etc/grub.conf file, it would fol­low the point­er and show you the con­tents of the ../boot/grub/grub.conf file. To cre­ate a sym­bol­ic link, use the -s op­tion with the ln com­mand:

ln -s <target> <link_name>

ln -s /etc/passwd mypasswd
ls -l mypasswd

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Con­sid­er This: No­tice that the first bit of the ls ‑l out­put is the l char­ac­ter, in­di­cat­ing that the file type is a link.

Com­par­ing Hard and Sym­bol­ic Links

While hard and sym­bol­ic links have the same re­sult, the dif­fer­ent tech­niques pro­duce dif­fer­ent ad­van­tages and dis­ad­van­tages. In fact, the ad­van­tage of one tech­nique com­pen­sates for a dis­ad­van­tage of the oth­er tech­nique.

Ad­van­tage: Hard links don’t have a sin­gle point of fail­ure.

One of the ben­e­fits of us­ing hard links is that every file name for the file con­tent is equiv­a­lent. If you have five files hard linked to­geth­er, then delet­ing any four of these files would not re­sult in delet­ing the ac­tu­al file con­tents.

Re­call that a file is as­so­ci­at­ed with a unique in­ode num­ber. As long as one of the hard linked files re­mains, then that in­ode num­ber still ex­ists, and the file da­ta still ex­ists.

Sym­bol­ic links, how­ev­er, have a sin­gle point of fail­ure: the orig­i­nal file. Con­sid­er the fol­low­ing ex­am­ple in which ac­cess to the da­ta fails if the orig­i­nal file is delet­ed. The mytest.txt file is a sym­bol­ic link to the text.txt file:

ls -l mytest.txt

lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt

more test.txt

hi there

more mytest.txt

hi there

If the orig­i­nal file, the test.txt file is re­moved, then any files linked to it, in­clud­ing the mytest.txt file, fail:

rm test.txt
more mytest.txt

mytest.txt: No such file or directory

ls -l mytest.txt

lrwxrwxrwx. 1 sysadmin sysadmin 8 Oct 31 13:29 mytest.txt -> test.txt

Ad­van­tage: Soft links are eas­i­er to see.

Some­times it can be dif­fi­cult to know where the hard links to a file ex­ist. If you see a reg­u­lar file with a link count that is greater than one, you can use the find com­mand with the -inum search cri­te­ria to lo­cate the oth­er files that have the same in­ode num­ber. To find the in­ode num­ber you would first use the ls ‑i com­mand:

ls -i file.original

278772 file.original

find / -inum 278772 2> /dev/null

/home/sysadmin/file.hard.1 
/home/sysadmin/file.original

Soft links are much more vi­su­al, not re­quir­ing any ex­tra com­mands be­yond the ls com­mand to de­ter­mine the link:

ls -l mypasswd

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 mypasswd -> /etc/passwd

Ad­van­tage: Soft links can link to any file.

Since each file sys­tem (par­ti­tion) has a sep­a­rate set of in­odes, hard links can­not be cre­at­ed that at­tempt to cross file sys­tems:

ln /boot/vmlinuz-2.6.32-358.6.1.el6.i686 Linux.Kernel

ln: creating hard link `Linux.Kernel' => `/boot/vmlinuz-2.6.32-358.6.1.el6.i686': Invalid cross-device link

In the pre­vi­ous ex­am­ple, a hard link was at­tempt­ed to be cre­at­ed be­tween a file in the /​​​boot file sys­tem and the / file sys­tem; it failed be­cause each of these file sys­tems has a unique set of in­ode num­bers that can't be used out­side of the filesys­tem.

How­ev­er, be­cause a sym­bol­ic link points to an­oth­er file us­ing a path­name, you can cre­ate a soft link to a file in an­oth­er filesys­tem:

ln -s /boot/vmlinuz-2.6.32-358.6.1.el6.i686 Linux.Kernel
ls -l Linux.Kernel

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 Linux.Kernel -> /boot/vmlinuz-2.6.32-358.6.1.el6.i686

Ad­van­tage: Soft links can link to a di­rec­to­ry.

An­oth­er lim­i­ta­tion of hard links is that they can­not be cre­at­ed on di­rec­to­ries. The rea­son for this lim­i­ta­tion is that the op­er­at­ing sys­tem it­self us­es hard links to de­fine the hi­er­ar­chy of the di­rec­to­ry struc­ture. The fol­low­ing ex­am­ple shows the er­ror mes­sage that is dis­played if you at­tempt to hard link to a di­rec­to­ry:

ln /bin binary

ln: `/bin': hard link not allowed for directory

Link­ing to di­rec­to­ries us­ing a sym­bol­ic link is per­mit­ted:

ln -s /bin binary
ls -l binary

lrwxrwxrwx. 1 sysadmin sysadmin 11 Oct 31 13:17 binary -> /bin

Ref­er­ences

• Red Hat Docs: An in­tro­duc­tion to Lin­ux Ac­cess Con­trol Lists (ACLs)
• Ja­va T Point: Ad­vanced File Per­mis­sion
• Geeks for Geeks: Ad­vance File Per­mis­sions in Lin­ux

Reg­is­ter: Lin­ux Serv­er

Идентифициране

Разработване

Авторизиране

Утвърждаване

Spas

Spas

Spas

Spas

14.07.2022

14.07.2022

14.07.2022

26.09.2022

28211

28216

28218 

31934