Changement des permissions : chmod, chown et chgrp

Les permissions et les bits de permissions : l'inode de chaque fichier contient un champ dont les bits
dfinissent qui peut faire quoi avec ce fichier :
le bit R, Read : s'il est arm, la lecture est autorise, dsarm, il interdit de lire le fichier.
le bit W, Write : il contrle de la mme manire l'criture sur le fichier et la possibilit de le
supprimer.
le bit X, excute : pour un fichier, il contrle la possibilit de l'excuter (si c'est un excutable ou
non). Pour un rpertoire, il permet ou il interdit l'accs ce rpertoire.

Certaines combinaisons n'ont pas de sens : un fichier avec w arm et r, et x dsarms ne peut tre
que modifi ou effac, mais pas lu ni excut, ce qui est utile ! De mme x arm et r dsarm vous
donnent un fichier que vous pouvez certes excuter aprs l'avoir charg, mais vous ne pouvez pas le
charger en lecture, car il n'est pas lisible...
En fait chaque fichier possde trois bits r, trois w et trois x, ce qui fait neuf en tout. Le premier trio
rwx dfinit les permissions pour le propritaire du fichier (c'est dire pour toute tche dont l'UID
correspond l'UID du fichier), le second pour tous les utilisateurs membres du groupe auquel
appartient ce fichier, et enfin le troisime pour tous les autres :
ex : lslpermet de voir ces bits

Vous savez dclarer les droits des utilisateurs par dfaut en utilisant la commande interne umask
(voir le chapitre 2 : commandes usuelles), mais il faut encore pouvoir modifier les bits de permissions
votre convenance :
chmod, CHange MODe, cette commande relativement complexe matriser modifie les permissions
daccs de chacun des fichiers indiqus, en suivant lindication de mode, qui peut tre une
reprsentation symbolique du changement effectuer, ou un nombre octal reprsentant le motif
binaire des nouvelles autorisations :
ex : chmodpermissionsfichiers
chmodu+rw,g+rw,orwtiti.txtchange les permissions du fichier en mode symbolique
chmod650 titi.txtchange les permissions du fichier titi.txt en mode octal

La manire la plus courante de reprsenter des permissions est le mode chiffr en octal :
4, 2, 1 la valeur octale est la reprsentation numrique ou chiffre des permissions de la forme
symbolique (r, w, x).

Plutt que d'utiliser le mode des permissions sous la reprsentation de nombres octaux (421), nous
allons plutt nous intresser la reprsentation symbolique. La reprsentation symbolique a la forme
suivante [ugo]+/[rwx] :
u, User, il s'agit des permissions du propritaire (400, 200, 100)
g, Group, il s'agit des permissions des utilisateurs du groupe auquel appartient le fichier (40, 20, 10)
o, Other, celles des autres utilisateurs (4, 2, 1).
+, Plus, le signe positif ajoute la permission
-, Moins, le signe ngatif enlve le permission
=, Egal , le signe gal fixe une permission

r, w, x, Read, Write, excute la combinaison de permissions concernes :

ex : chmodu+rwxdonne le droit de lire, crire et excuter le fichier titi.txt son propritaire
chmodug+wautorise le propritaire ainsi que les utilisateurs du groupe modifier le fichier
chmodgorwx toto interdit tout accs au fichier tout le monde sauf le propritaire (et root !)

Vous pouvez galement utiliser la lettre a, qui est un raccourcis, pour ugo :
ex : chmoda+rpermet tout le monde de lire le fichier.

Version tendue des permissions :

A ces droits (*) viennent ce rajouter SUID (4000) , SGID ( 2000 ) et Sticky-bit (1000) :

SUID, Sticky User IDentificator :

Fichiers excutables : le processus rsultant d'un fichier excutable SUID (4000) possde les
permissions du propritaire du fichier.

SGID, Sticky Group IDentificator :

Fichiers excutables : le processus rsultant d'un fichier excutable SGID (2000) possde les
permissions du groupe du propritaire du fichier.
Rpertoires : les fichiers cres dans le rpertoires ont pour groupe du propritaire le groupe du
propritaire du rpertoire.

Sticky-Bit :
Fichiers excutables : le processus rsultant d'un fichier excutable Sticky-bit (1000) reste en
mmoire et son chargement est rapide.
Rpertoires : la suppression d'un fichier dans un rpertoire Sticky-bit n'est possible que pour le
propritaire.

Comment crire la permission "tendue" ?

Le SUID s'crit S ( la place du x du propritaire) si le propritaire n'a pas le droit d'excuter le fichier,
s dans le cas contraire
Le SGID s'crit S ( la place du x du groupe propritaire) si le groupe propritaire n'a pas la
permission d'excuter le fichier, s dans le cas contraire
Le Sticky bit s'crit T ( la place du x du droit "des autres utilisateurs" ) si les autres n'ont pas la
permission d'xecuter le fichier, t dans le cas contraire.

(*) Note : ces permissions n'ont pas d'effets sur les systmes de fichiers de type FAT.
Lorsque vous possdez un compte sur une station UNIX ou GNU/Linux (comme la vtre :), le
systme ne vous connat pas par votre nom mais par votre User IDentificator (UID), numro qui vous
est attribu au moment de la cration du compte : rappelez vous, lorsque vous avez utilis la
commande useradd. Cette commande permet aussi d'attribuer avec l'option u l'UID de l'utilisateur
crer. En plus des utilisateurs, les systmes UNIX gre galement la notion de groupe : chaque
groupe, identifi bien sr par son Group Identificator (GID), dfinit simplement un ensemble
d'utilisateurs (c'est dire un ensemble d'UIDs). Lorsque vous crez un compte, vous avez aussi
galement la possibilit de choisir le GID du groupe auquel appartient l'utilisateur soit en l'attribuant
un groupe existant avec l'option g soit en le crant (option idem). Il y a plusieurs coles : certains
prconisent qu'il faut crer un groupe pour chaque utilisateur, d'autres disent de rassembler tous les
utilisateurs dans un groupe ddi appel users.
Pour rappel l'UID et le GID de chaque utilisateur sont stocks dans le fichier /etc/passwd. Lorsque
vous vous "loguez" grce l'invite, le systme d'authentification va consulter ce fichier pour vrifier la
validit de votre nom et de votre mot de passe et en cas de succs, il renvoie l'UID et le GID de
l'utilisateur autoris se connecter. Ce fichier est d'ailleurs celui qui dfinit le nom de l'utilisateur :
vous pouvez renommer un utilisateur en ditant ce fichier (mais ne modifiez surtout pas son UID !)
Un utilisateur peut bien videmment appartenir plus d'un groupe. A cette fin, le fichier /etc/group
contient, pour chaque groupe, son GID et les noms d'utilisateurs membres (sauf ceux dclars par
dfaut dans /etc/passwd). Il faut savoir qu' tout moment, chaque fichier, chaque tche, chaque
priphrique, etc ... possde exactement un UID et un GID. En plus de possder un UID et un GID,
chaque fichier est aussi dfini par un bit, BInary digiT de permission spcial : le bit setuid. A quoi
sert-il ?

Sous UNIX, il y a une rgle d'or en ce qui concerne les privilges, la rgle d'endossement : quand un
processus est lanc, il acquiert les droits de celui qui l'a lanc (videmment, cela cre des
problmes). Ainsi, si un utilisateur veut modifier son mot de passe, il ne le pourra pas si on se
contente de cela ; en effet, le fichier /etc/passwd n'est accessible en criture que pour le root!
D'o l'intrt du bit setuid. En temps normal, il est positionn 0, et la rgle d'endossement
s'applique. Mais quand il est positionn 1, il est lanc avec les droits de son propritaire, c'est--dire
les droits de root, et l'utilisateur pourra modifier son mot de passe. Nous allons maintenant voir
comment on utilise tout ceci pour grer la scurit. Les UID et GID (*) de valeur 0 sont ceux dont les
droits ne sont pas vrifis et sont par consquent rservs au root. Vous pouvez donc changer le
nom du root en modifiant le nom associ UID 0, ce qui est vraiment une trs mauvaise ide !

Nous avons vu que chaque fichier (entre autres) possde un UID et un GID. En tapant lsl. vous
affichez directement le nom de l'utilisateur et du groupe qui correspondent l'UID et au GID plutt
que les valeurs numriques. L'UID du fichier est ce qu'on appelle habituellement le "propritaire" du
fichier et le GID du fichier le "groupe" du fichier. Il faut d'ailleurs bien comprendre que ces deux
champs sont indpendants : un fichier peut trs bien faire partie d'un groupe dont le propritaire n'est
pas membre. Lire l'UID et le GID d'un fichier, est utile, mais il faut aussi pouvoir les modifier :
 chown, CHange OWNer permet (entre autres) de modifier le propritaire d'un fichier : donne un
fichier quelqu'un d'autre. Toutefois, seul le root peut l'utiliser, les simples utilisateurs n'ont aucun
autre moyen de se dbarrasser d'un fichier que de l'effacer :
chownnom_de_propritairefichiers
ex : chowntototiti.txtchange de propritaire : le nouveau propritaire est toto
Vous pouvez entrer directement l'UID au lieu du nom et faire beaucoup d'autres : manchown:
ex : chown501titi.txt

chgrp, CHange GRouP symtrique la commande chown : modifie le groupe d'un fichier.
Contrairement chown, elle peut tre appele par un simple utilisateur, condition qu'il soit membre
du groupe auquel il veut donner le fichier. Le root n'a naturellement aucune restriction de ce type :
chgrpnom_de_groupefichiers
ex : chgrptototiti.txtchange de groupe : le nouveau groupe est toto
Vous pouvez entrer directement l'UID au lieu du nom et faire beaucoup d'autres : manchgrp:
ex : chgrp501titi.txt

(*) Note : en fait, les explications ci-dessus sont simples car en effet hormis l'uid, il existe deux
autres donnes le RUID, Real UID, l'UID du propritaire du fichier (il est immuable) et l'EUID,
Effective UID, l'UID qui est pris en compte lors de l'excution du processus (process). Il dtermine les
droits d'accs du process au systme. Normalement, RUID=EUID=> le process hrite des droits
de l'appeleur, la rgle de l'endossement. Mais, quand le bit setuid est positionn par un process,
l'euid du process a pour valeur l'uid du propritaire du fichier. Donc, si le process est setuid root, il
aura pour ruid celui de l'utilisateur qui l'a lanc, mais l'euid du root. Ainsi, dans le cas de /
etc/passwd qui doit tre modifi par un utilisateur voulant changer de password, comme /
etc/passwd a le bit setuidroot, le kernel modifie l'euid de /etc/passwd qui devient celui du
root afin que l'utilisateur puisse y avoir accs en criture pour modifier son mot de passe (rappelons
que le ruid est immuable). En effet, un process n'a pas besoin d'avoir toujours l'EUIID root. Il a
donc la possibilit de modifier son euid. En fait, quand l'euid du programme est modifi
(/etc/passwd en l'occurence), son ancien euid (qui est gal au ruid de l'utilisateur qui a lanc le
programme) est mmoris dans un bit de sauvegarde (le dernier apprendre) : le SUID, Saved UID.
Par consquent, pour limiter les attaques (en effet, si le programme garde son euid root n'importe
quel utilisateur invit qui excute /etc/passwd aura les droits en criture dessus !), le programme
va modifier son euid au plus vite en ruid. L'ancien euid (celui du root) est plac dans le suid et
le ruid est copi dans l'euid. Puis, plus tard, quand les appels systme (syscalls) ncessitent des
privilges correspondant au propritaire du fichier, on remplace le suid dans l'euid (gain de temps).