comprendre le suid et le sgid : petit exemple
Francois Lafont
J'essaye de comprendre les droits sur Linux et j'avoue avoir du mal �
bien comprendre le fonctionnement de suid et sgid. Voici mon exemple.
Dans toute la suite, le fichier ex�cutable touch.exe est un fichier issu
de la compilation du source en langage C suivant :
(je pr�cise que j'ai bien vu sur le Web que cette mani�re de coder n'est
pas un exemple � suivre, mais ce n'est pas du tout l'objet de ce fil.
L'objet de ce fil c'est suid et sgid.)
//----------------------
#include <stdio.h>
#include <stdlib.h>
int main (void)
{
system("touch fichier.txt");
return 0;
}
//----------------------
J'ai un dossier d qui contient l'ex�cutable touch.exe :
#-----------------------------
# ls -l
drwxrwxr-x 2 sophie sophie 4096 2011-02-06 03:28 d
# ls -l d/
---------x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
# chmod u+s d/touch.exe
# ls -l d/
---S-----x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
#-----------------------------
Vous pouvez constater que seul l'utilisateur sophie ainsi que les
membres du groupe sophie peuvent cr�er des fichiers dans le dossier d.
De plus, le fichier touch.exe est ex�cutable pour "les autres" et le
suid est activ� (mais pas le droit x pour l'utilisateur sophie).
Maintenant, j'ouvre un shell avec l'utilisateur francois qui ne fait pas
partie du groupe sophie (son groupe effectif s'appelle francois) :
#-----------------------------
$ cd d/
$ ./touch.exe
$ ls -l
-rw-r--r-- 1 sophie francois 0 2011-02-06 03:32 fichier.txt
---S-----x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
#-----------------------------
Q1) le fichier fichier.txt est bien cr�� car, avec le suid, tout se
passe comme si le programme avait �t� lanc� par sophie. Pourquoi est-ce
que le groupe propri�taire de fichier.txt est francois ? J'aurais plut�t
pari� pour que ce soit sophie (ce qui se serait pass� si l'utilisateur
sophie avait lui-m�me ex�cut� le programme touch.exe).
Mais la suite me surprend encore plus.
Sous root, je supprime fichier.txt et je change les droits de touch.exe
comme ceci (suppression de suid et activation de sgid) :
#-----------------------------
# rm d/fichier.txt
# chmod u-s,g+s d/touch.exe
# ls -l d/
------S--x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
#-----------------------------
Ensuite, sous le compte francois, je tente d'ex�cuter touch.exe :
#-----------------------------
$ cd d/
$ ls -l
------S--x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
$ ./touch.exe
touch: impossible de faire un touch �fichier.txt�:
Permission non accord�e
#-----------------------------
Q2) Pourquoi est-ce que francois n'a pas la permission de faire un touh
? Pour moi, � cause du sgid sur touch.exe, l'utilisateur francois
b�n�ficie des droits du groupe propri�taire du fichier touch.exe, �
savoir le groupe sophie et donc il devrait pouvoir cr�er un fichier dans
le dossier d, non ?
Je pense que la question suivante est li�e � la pr�c�dente.
Q3) Si au lieu d'avoir '------S--x' dans les permissions de touch.exe
j'ai '------s--x' (c'est-�-dire qu'avec root j'ai fait chmod g+x
d/touch.exe), alors l� francois peut ex�cuter touch.exe et il a bien les
permissions pour cr�er fichier.txt. Pourquoi ?
Je suis surpris de cette dissym�trie entre le suid et le sgid : en effet
avec '---S-----x' comme droits sur touch.exe (ou m�me avec
'---s-----x'), pas de souci dans l'ex�cution de touch.exe. Mais en
revanche, c�t� sgid, je n'ai pas le m�me comportement suivant que j'ai
les droits '------S--x' ou '------s--x' sur touch.exe.
J'esp�re avoir �t� clair.
Merci d'avance pour votre aide.
--
Fran�ois Lafont
Luc Habert
> system("touch fichier.txt");
Attention, certains shells se débarrassent de droits obtenus via des bits s.
Il vaudrait mieux un open("fichier.txt", O_CREAT, 666).
> Q1) le fichier fichier.txt est bien créé car, avec le suid, tout se
> passe comme si le programme avait été lancé par sophie. Pourquoi est-ce
> que le groupe propriétaire de fichier.txt est francois ?
Les groupes sont orthogonaux aux utilisateurs. Le seul lien entre le groupe
sophie et l'utilisateur sophie est qu'au login, si on se logue en tant que
sophie, on se fait attribuer le groupe sophie, mais c'est juste parce que
c'est marqué dans /etc/passwd, ce n'est pas un lien intangible.
> Q2) Pourquoi est-ce que francois n'a pas la permission de faire un touh
> ? Pour moi, à cause du sgid sur touch.exe, l'utilisateur francois
> bénéficie des droits du groupe propriétaire du fichier touch.exe, à
> savoir le groupe sophie et donc il devrait pouvoir créer un fichier dans
> le dossier d, non ?
goto premier paragraphe
(Je ne sais pas si c'est le problème, mais c'est la première chose à faire
pour clarifier la situation.)
Benoit Izac
le 06/02/2011 à 04:23, Francois Lafont a écrit dans le message
<4d4e1420$0$31862$426a...@news.free.fr> :
> $ ls -l
> -rw-r--r-- 1 sophie francois 0 2011-02-06 03:32 fichier.txt
> ---S-----x 1 sophie sophie 7141 2011-02-06 03:28 touch.exe
> #-----------------------------
>
> Q1) le fichier fichier.txt est bien créé car, avec le suid, tout se
> passe comme si le programme avait été lancé par sophie. Pourquoi est-ce
> que le groupe propriétaire de fichier.txt est francois ? J'aurais plutôt
> parié pour que ce soit sophie (ce qui se serait passé si l'utilisateur
> sophie avait lui-même exécuté le programme touch.exe).
Parce que le groupe effectif n'a pas changé. Tu peux essayé ce programme
pour voir les appartenances réelles et effectives :
#include <stdio.h>
#include <stdlib.h>
#include <sys/stat.h>
#include <unistd.h>
int main(void)
{
const char *filename = "test.txt";
FILE *fp;
struct stat s;
printf("uid: %5d, gid: %5d\n", getuid(), getgid());
printf("euid: %5d, egid: %5d\n", geteuid(), getegid());
fp = fopen(filename, "w");
if (fp == NULL) {
perror("fopen");
exit(1);
}
if (stat(filename, &s) == -1) {
perror("stat");
exit(2);
}
printf("%s uid: %5d, gid: %5d, mode: %o\n",
filename, s.st_uid, s.st_gid, s.st_mode);
fclose(fp);
unlink(filename);
return 0;
}
> Q2) Pourquoi est-ce que francois n'a pas la permission de faire un touh
> ? Pour moi, à cause du sgid sur touch.exe, l'utilisateur francois
> bénéficie des droits du groupe propriétaire du fichier touch.exe, à
> savoir le groupe sophie et donc il devrait pouvoir créer un fichier dans
> le dossier d, non ?
>
> Je pense que la question suivante est liée à la précédente.
>
> Q3) Si au lieu d'avoir '------S--x' dans les permissions de touch.exe
> j'ai '------s--x' (c'est-à-dire qu'avec root j'ai fait chmod g+x
> d/touch.exe), alors là francois peut exécuter touch.exe et il a bien les
> permissions pour créer fichier.txt. Pourquoi ?
C'est du au fait qu'avoir le bit S_ISGIG a 1 et le bit S_IXGRP a 0 permet
de faire du "mandatory locking".
C'est expliqué dans chmod(2) :
| S_ISGID (02000) set-group-ID (set process effective group ID on
| execve(2); mandatory locking, as described in
| fcntl(2); take a new file's group from parent direc‐
| tory, as described in chown(2) and mkdir(2))
et dans fnctl(2) :
| To make use of mandatory locks, mandatory locking must be enabled both
| on the file system that contains the file to be locked, and on the file
| itself. Mandatory locking is enabled on a file system using the "-o
| mand" option to mount(8), or the MS_MANDLOCK flag for mount(2). Manda‐
| tory locking is enabled on a file by disabling group execute permission
| on the file and enabling the set-group-ID permission bit (see chmod(1)
| and chmod(2)).
--
Benoit Izac
Francois Lafont
> Les groupes sont orthogonaux aux utilisateurs. Le seul lien entre le groupe
> sophie et l'utilisateur sophie est qu'au login, si on se logue en tant que
> sophie, on se fait attribuer le groupe sophie, mais c'est juste parce que
> c'est marqué dans /etc/passwd, ce n'est pas un lien intangible.
Ok, mais justement à ce propos, je me suis souvent demandé ce qui
rendait particulier le groupe primaire d'un utilisateur ? Je m'explique.
Un utilisateur peut appartenir à plusieurs groupes (c'est le cas de
l'utilisateur francois sur mon système). Le groupe primaire est celui
qui apparaît dans /etc/passwd. Mais à part ça, c'est quoi sa
particularité ? Par exemple, si je change le groupe primaire
(personnellement, j'avais bêtement édité /etc/passwd et je m'étais
reconnecté au système), l'utilisateur a les mêmes droits. J'avais
l'impression qu'au niveau des droits le groupe primaire ne joue pas de
rôle particulier (si un fichier f a pour groupe propriétaire G, j'ai les
mêmes droits sur f que G soit mon groupe primaire ou non, me semble-t-il).
En fait, la *seule* chose que j'ai pu constater et qui rend le groupe
primaire particulier, c'est au niveau de la création des fichiers, où le
groupe propriétaire du fichier est toujours le groupe primaire du
créateur au départ.
--
François Lafont
Benoit Izac
le 06/02/2011 à 18:20, Francois Lafont a écrit dans le message
<4d4ed859$0$20786$426a...@news.free.fr> :
> En fait, la *seule* chose que j'ai pu constater et qui rend le groupe
> primaire particulier, c'est au niveau de la création des fichiers, où le
> groupe propriétaire du fichier est toujours le groupe primaire du
> créateur au départ.
Pas toujours vrai : si le répertoire dans lequel tu souhaites créer un
fichier a le bit set-group-ID (S_ISGID), ton fichier appartiendra au
même groupe que le répertoire.
--
Benoit Izac
Francois Lafont
>> Q1) le fichier fichier.txt est bien créé car, avec le suid, tout se
>> passe comme si le programme avait été lancé par sophie. Pourquoi est-ce
>> que le groupe propriétaire de fichier.txt est francois ? J'aurais plutôt
>> parié pour que ce soit sophie (ce qui se serait passé si l'utilisateur
>> sophie avait lui-même exécuté le programme touch.exe).
>
> Parce que le groupe effectif n'a pas changé.
Ok, alors après quelques recherches sur le Web, si j'ai bien compris un
processus possède (entre autres) :
- un UID qui est l'id réel de l'utilisateur qui a lancé le processus
- un EUID qui l'id effectif du processus (c'est lui qui conditionne les
droits d'accès)
Sachant qu'en général UID == EUID, sauf si le prog exécutable
responsable du processus avait le suid activé où dans ce cas le EUID est
l'identifiant du propriétaire de l'exécutable. C'est bien cela ?
Et on a la même chose, si j'ai bien compris, avec le GID et le EGID d'un
processus. Et dans mon test de la question Q1, c'est seulement le EUID
qui a changé mais le GUID est resté égal à celui de l'utilisateur francois.
Mais il y a une chose que je n'arrive pas trop à comprendre. Sur mon
système (Ubuntu 10.04), *au niveau des groupes*, les droits d'accès ne
dépendent pas seulement du groupe primaire de l'utilisateur mais de
l'ensemble des groupes auxquels il appartient. Or dans dans un
processus, seul le groupe primaire est stocké. Comment le processus fait
pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
droit de lire tel fichier si toto n'est pas mon groupe primaire ?
> Tu peux essayé ce programme
> pour voir les appartenances réelles et effectives : [snip]
Parfait, merci bien, ça sera pour moi instructif. Je n'y connais rien en
C, mais en lisant le programme, je crois comprendre qu'il crée un
fichier fichier.txt dans le répertoire courant. Or, pourtant, même en
effectuant le programme sous root, aucun fichier n'est créé, est-ce normal ?
> C'est du au fait qu'avoir le bit S_ISGIG a 1 et le bit S_IXGRP a 0 permet
> de faire du "mandatory locking".
Clairement, vu les citations, il est évident que tu as montré du doigt
la réponse à la question, merci.
> et dans fcntl(2) :
> | To make use of mandatory locks, mandatory locking must be enabled both
> | on the file system that contains the file to be locked, and on the file
> | itself. Mandatory locking is enabled on a file system using the "-o
> | mand" option to mount(8), or the MS_MANDLOCK flag for mount(2).
Je fais mes tests dans le /home en général et pourtant dans le montage
de /home il n'y a pas d'option qui pourrait ressembler à ce qui est
écrit ci-dessus ?
$ mount | grep '/home '
/dev/sdb1 on /home type ext3 (rw,relatime)
Par ailleurs, j'ai bien tenté de lire fcntl(2), notamment avant ce que
tu cites, et j'ai compris comment on activait le "mandatory locking" sur
un fichier (exactement en faisant ce que j'ai fait sur le test de la
question Q2), mais je ne comprends pas :
a) ce que fait exactement le "mandatory locking"
b) et a fortiori à quoi ça sert
Je tente une réponse pour a) seulement :
a) il désactive l'effet du sgid si le droit x pour le groupe est à 0 (en
fait, ça c'est ce que j'ai pu constater avec mon test, mais à lire la
page man, c'est bien plus compliqué que ça).
--
François Lafont
Luc Habert
> En fait, la *seule* chose que j'ai pu constater et qui rend le groupe
> primaire particulier, c'est au niveau de la création des fichiers, où le
> groupe propriétaire du fichier est toujours le groupe primaire du
> créateur au départ.
C'est ça.
Francois Lafont
Le 06/02/2011 18:38, Benoit Izac a �crit :
>> En fait, la *seule* chose que j'ai pu constater et qui rend le groupe
>> primaire particulier, c'est au niveau de la cr�ation des fichiers, o� le
>> groupe propri�taire du fichier est toujours le groupe primaire du
>> cr�ateur au d�part.
>
> Pas toujours vrai : si le r�pertoire dans lequel tu souhaites cr�er un
> fichier a le bit set-group-ID (S_ISGID), ton fichier appartiendra au
> m�me groupe que le r�pertoire.
Oui tu as raison (en plus je le savais �a).
Mais sur le fond, mis � part au moment de la cr�ation d'un fichier,
qu'est-ce qu'un groupe primaire a de particulier par rapport � un groupe
auquel appartient un utilisateur donn� ?
--
Fran�ois Lafont
Benoit Izac
le 06/02/2011 à 18:49, Francois Lafont a écrit dans le message
<4d4edf31$0$26423$426a...@news.free.fr> :
> Sachant qu'en général UID == EUID, sauf si le prog exécutable
> responsable du processus avait le suid activé où dans ce cas le EUID est
> l'identifiant du propriétaire de l'exécutable. C'est bien cela ?
Oui.
> Et on a la même chose, si j'ai bien compris, avec le GID et le EGID d'un
> processus. Et dans mon test de la question Q1, c'est seulement le EUID
> qui a changé mais le GUID est resté égal à celui de l'utilisateur francois.
>
> Mais il y a une chose que je n'arrive pas trop à comprendre. Sur mon
> système (Ubuntu 10.04), *au niveau des groupes*, les droits d'accès ne
> dépendent pas seulement du groupe primaire de l'utilisateur mais de
> l'ensemble des groupes auxquels il appartient. Or dans dans un
> processus, seul le groupe primaire est stocké. Comment le processus fait
> pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
> droit de lire tel fichier si toto n'est pas mon groupe primaire ?
C'est via /etc/group. Tu peux taper la commande « id » pour avoir une
idée précise de ton uid, ton gid et les groupes auxquels tu appartiens.
>> Tu peux essayé ce programme
>> pour voir les appartenances réelles et effectives : [snip]
>
> Parfait, merci bien, ça sera pour moi instructif. Je n'y connais rien en
> C, mais en lisant le programme, je crois comprendre qu'il crée un
> fichier fichier.txt dans le répertoire courant. Or, pourtant, même en
> effectuant le programme sous root, aucun fichier n'est créé, est-ce normal ?
Oui. ;-)
En fait j'aurais du ajouter un commentaire : tu as la fonction unlink(2)
qui fait le ménage à la fin ; tu peux la commenter/supprimer si tu
souhaites conserver le fichier.
> a) ce que fait exactement le "mandatory locking"
> b) et a fortiori à quoi ça sert
Le locking, c'est un méthode pour empêcher que plusieurs processus
accèdent au même fichier en même temps (lock = verrouiller).
Imagine par exemple un fichier de log avec un programme qui a plusieurs
instances : il serait fâcheux que le processus A commence à écrire
quelque chose et que quelques instants plus tard, alors que A n'a pas
fini d'écrire, un autre processus B écrive aussi. Tu te retrouverais
avec un fichier de log incompréhensible car tout mélangé.
Après, le mandatory locking tel que défini dans fcntl(2) est quelque
chose que je ne maîtrise pas ; je ne m'aventurerai donc pas dans sa
description.
--
Benoit Izac
Nicolas George
<4d4edf31$0$26423$426a...@news.free.fr>, a écrit :
> Or dans dans un
> processus, seul le groupe primaire est stocké.
Qu'est-ce qui te fait dire ça ?
> Comment le processus fait
> pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
> droit de lire tel fichier si toto n'est pas mon groupe primaire ?
Ce n'est pas le processus qui le sait, c'est le noyau.
Francois Lafont
Le 06/02/2011 19:32, Benoit Izac a écrit :
>> processus, seul le groupe primaire est stocké. Comment le processus fait
>> pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
>> droit de lire tel fichier si toto n'est pas mon groupe primaire ?
>
> C'est via /etc/group. Tu peux taper la commande « id » pour avoir une
> idée précise de ton uid, ton gid et les groupes auxquels tu appartiens.
Ok, si un processus tente d'accéder en lecture par exemple un fichier f
dont le groupe propriétaire G n'est pas le groupe primaire de
l'utilisateur responsable du processus, le noyau ira consulter le
fichier /etc/group pour voir si l'utilisateur est membre ou non du
groupe G. C'est bien cela ? J'image alors que ce fichier /etc/group est
stocké dans la RAM ou un truc comme ça, afin d'éviter les accès disque.
>> Or, pourtant, même en
>> effectuant le programme sous root, aucun fichier n'est créé, est-ce normal ?
>
> Oui. ;-)
>
> En fait j'aurais du ajouter un commentaire : tu as la fonction unlink(2)
> qui fait le ménage à la fin ; tu peux la commenter/supprimer si tu
> souhaites conserver le fichier.
Ah, très bien merci.
> Le locking, c'est un méthode pour empêcher que plusieurs processus
> accèdent au même fichier en même temps (lock = verrouiller).
>
> Imagine par exemple un fichier de log avec un programme qui a plusieurs
> instances : il serait fâcheux que le processus A commence à écrire
> quelque chose et que quelques instants plus tard, alors que A n'a pas
> fini d'écrire, un autre processus B écrive aussi. Tu te retrouverais
> avec un fichier de log incompréhensible car tout mélangé.
Ok, je comprends.
--
François Lafont
Francois Lafont
>> Or dans dans un
>> processus, seul le groupe primaire est stocké.
>
> Qu'est-ce qui te fait dire ça ?
Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur
le Web, je suis tombé sur cette page :
http://tldp.org/HOWTO/Secure-Programs-HOWTO/processes.html
Et je vois qu'il y a comme attribut le GID et le EGID, mais pas un truc
qui ressemblerait à la liste des GID de tous les groupes auquel
l'utilisateur (ayant lancé le processus) appartient.
Mais dans l'absolu, je ne suis sûr de rien. J'essaye juste de comprendre
un petit peu.
>> Comment le processus fait
>> pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
>> droit de lire tel fichier si toto n'est pas mon groupe primaire ?
>
> Ce n'est pas le processus qui le sait, c'est le noyau.
Ok, merci pour la précision.
--
François Lafont
Nicolas George
> le noyau ira consulter le
> fichier /etc/group pour voir si l'utilisateur est membre ou non du
> groupe G. C'est bien cela ?
Non, pas du tout. D'une manière générale, le noyau ne va presque jamais lire
de lui-même des fichiers, et jamais des fichiers texte qu'il faudrait
interpréter.
Benoit Izac
le 06/02/2011 à 20:20, Francois Lafont a écrit dans le message
<4d4ef481$0$23921$426a...@news.free.fr> :
> Ok, si un processus tente d'accéder en lecture par exemple un fichier f
> dont le groupe propriétaire G n'est pas le groupe primaire de
> l'utilisateur responsable du processus, le noyau ira consulter le
> fichier /etc/group pour voir si l'utilisateur est membre ou non du
> groupe G. C'est bien cela ? J'image alors que ce fichier /etc/group est
> stocké dans la RAM ou un truc comme ça, afin d'éviter les accès disque.
Je n'ai aucune idée de comment le noyau agit. La seule chose importante
à savoir c'est que lorsque tu veux accéder à un fichier, les tests sont
fait dans cet ordre :
1. ton euid est 0 (tu es root) -> permission accordée
2. ton euid est le même que celui du fichier et que tu as les
permissions qui vont bien (lecture/écriture/exécution) -> permission
accordée
3. ton egid est le même que celui du fichier et que tu as les
permissions qui vont bien (lecture/écriture/exécution) -> permission
accordée
4. les permissions sont ok pour tout le monde (other) -> permission
accordée
5. permission refusée
Ensuite, ce que fait le noyau Linux en interne n'est pas forcément ce
que fait un autre ; pour un utilisateur ou un programmeur qui respecte
POSIX, ça n'a aucune importance car le comportement est parfaitement
défini (sauf pour tout ce qui est marqué comme « implementation
defined » bien évidemment).
--
Benoit Izac
Nicolas George
> Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur
> le Web, je suis tombé sur cette page :
>
> http://tldp.org/HOWTO/Secure-Programs-HOWTO/processes.html
>
> Et je vois qu'il y a comme attribut le GID et le EGID, mais pas un truc
> qui ressemblerait à la liste des GID de tous les groupes auquel
> l'utilisateur (ayant lancé le processus) appartient.
Et « supplemental groups - a list of groups (GIDs) in which this user has
membership. » juste en dessous ?
Francois Lafont
>> le noyau ira consulter le
>> fichier /etc/group pour voir si l'utilisateur est membre ou non du
>> groupe G. C'est bien cela ?
>
> Non, pas du tout. D'une manière générale, le noyau ne va presque jamais lire
> de lui-même des fichiers, et jamais des fichiers texte qu'il faudrait
> interpréter.
Ok, mais alors comment ça se passe en gros. Tiens, justement, l'exemple
de Benoit est tout à fait à propos.
Benoit a écrit :
> Je n'ai aucune idée de comment le noyau agit. La seule chose importante
> à savoir c'est que lorsque tu veux accéder à un fichier, les tests sont
> fait dans cet ordre :
> 1. ton euid est 0 (tu es root) -> permission accordée
> 2. ton euid est le même que celui du fichier et que tu as les
> permissions qui vont bien (lecture/écriture/exécution) -> permission
> accordée
> 3. ton egid est le même que celui du fichier et que tu as les
> permissions qui vont bien (lecture/écriture/exécution) -> permission
> accordée
> 4. les permissions sont ok pour tout le monde (other) -> permission
> accordée
> 5. permission refusée
C'est là où j'ai un problème avec cet «algorithme», voici un exemple qui
me semble en contradiction :
#---------------
$ whoami # je suis connecté en tant que francois
francois
$ ls -l # seuls root et les membres de "adm" peuvent lire f.txt
-rw-r----- 1 root adm 28 2011-02-06 21:03 f.txt
$ id # mais je fais partie du groupe adm, même si ce n'est pas
# mon groupe primaire
uid=1000(francois) gid=1000(francois) groupes=4(adm), 20(dialout),
24(cdrom), # je coupe
$ cat f.txt # et j'ai le droit de lire f.txt
Blabla blabla
blabla blabla
#---------------
--
François Lafont
Benoit Izac
le 06/02/2011 à 21:13, Francois Lafont a écrit dans le message
<4d4f00fc$0$17749$426a...@news.free.fr> :
>> Je n'ai aucune idée de comment le noyau agit. La seule chose importante
>> à savoir c'est que lorsque tu veux accéder à un fichier, les tests sont
>> fait dans cet ordre :
>> 1. ton euid est 0 (tu es root) -> permission accordée
>> 2. ton euid est le même que celui du fichier et que tu as les
>> permissions qui vont bien (lecture/écriture/exécution) -> permission
>> accordée
>> 3. ton egid est le même que celui du fichier et que tu as les
>> permissions qui vont bien (lecture/écriture/exécution) -> permission
>> accordée
>> 4. les permissions sont ok pour tout le monde (other) -> permission
>> accordée
>> 5. permission refusée
>
> C'est là où j'ai un problème avec cet «algorithme», voici un exemple qui
> me semble en contradiction :
Je ne vois pas ce qui est contradictoire :
> #---------------
> $ whoami # je suis connecté en tant que francois
> francois
>
> $ ls -l # seuls root et les membres de "adm" peuvent lire f.txt
> -rw-r----- 1 root adm 28 2011-02-06 21:03 f.txt
>
> $ id # mais je fais partie du groupe adm, même si ce n'est pas
> # mon groupe primaire
> uid=1000(francois) gid=1000(francois) groupes=4(adm), 20(dialout),
> 24(cdrom), # je coupe
1. tu n'es pas root -> refusé
2. ton euid n'est pas root (le fichier appartient à root) -> refusé
3. tu es dans le groupe adm et ses membres ont le droit de le lire ->
accordé
> $ cat f.txt # et j'ai le droit de lire f.txt
> Blabla blabla
> blabla blabla
> #---------------
--
Benoit Izac
Francois Lafont
Ah, pardon je n'avais pas bien lu. À ma (petite) décharge, j'ai consulté
plusieurs pages Web (je les ai mal consultées, la preuve) comme par
exemple celle-ci aussi :
http://www.linux-france.org/article/dalox/unix03.htm
et pas mal d'autres où il n'y avait pas mention de cette «list of groups ».
Bon, toutes mes excuses. Du coup, je pense que les choses sont à peu
près claires pour l'essentiel, mis à part cette histoire de "mandatory
locking". Mais ce n'est pas important je n'en aurai très certainement
jamais l'utilité. Même le bit sgid, je crois bien qu'il ne me servira pas.
Merci à tous pour vos explications. Une fois encore, j'ai appris des
choses.
--
François Lafont
Francois Lafont
> Je ne vois pas ce qui est contradictoire : [couic]
Oui, maintenant l'affaire est entendue.
Disons que le egid (=1000) ne correspond pas � celui du groupe adm (=4)
du fichier f.txt, mais comme le processus poss�de la liste des groupes
dont francois est membre (comme expliqu� dans la page
http://tldp.org/HOWTO/Secure-Programs-HOWTO/processes.html), le noyau
peut finalement accorder l'acc�s en lecture.
--
Fran�ois Lafont
Hugues
Ce cher Francois Lafont <francoi...@nospam.invalid> a posté :
> Bonjour Benoit,
>
> Le 06/02/2011 18:38, Benoit Izac a écrit :
>
>>> En fait, la *seule* chose que j'ai pu constater et qui rend le groupe
>>> primaire particulier, c'est au niveau de la création des fichiers, où le
>>> groupe propriétaire du fichier est toujours le groupe primaire du
>>> créateur au départ.
>>
>> Pas toujours vrai : si le répertoire dans lequel tu souhaites créer un
>> fichier a le bit set-group-ID (S_ISGID), ton fichier appartiendra au
>> même groupe que le répertoire.
>
> Oui tu as raison (en plus je le savais ça).
>
> Mais sur le fond, mis à part au moment de la création d'un fichier,
> qu'est-ce qu'un groupe primaire a de particulier par rapport à un groupe
> auquel appartient un utilisateur donné ?
Personnellement, je ne vois rien de particulier. Le groupe primaire a
toujours été pour moi synonyme de "groupe par défaut". Ni plus, ni moins.
D'ailleurs, pour cette raison, j'abhorre les "users groups", que je
m'empresse systématiquement de remplacer par un groupe "users" pour mes
comptes unix.
Ne serait-ce que pour éviter de confondre uid et gid..
--
Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Hugues
Ce cher Francois Lafont <francoi...@nospam.invalid> a posté :
> Comment le processus fait
> pour savoir qu'en tant que membre du groupe toto (par exemple) j'ai le
> droit de lire tel fichier si toto n'est pas mon groupe primaire ?
En regardant à quels groupes appartient l'EUID, je suppose.