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.
le 06/02/2011 à 20:20, Francois Lafont a écrit dans le message <4d4ef481$0$23921$ :
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
Bonjour,
le 06/02/2011 à 20:20, Francois Lafont a écrit dans le message
<4d4ef481$0$23921$426a34cc@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).
le 06/02/2011 à 20:20, Francois Lafont a écrit dans le message <4d4ef481$0$23921$ :
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
Francois Lafont , dans le message <4d4ef783$0$4946$, a écrit :
Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur le Web, je suis tombé sur cette page :
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 , dans le message
<4d4ef783$0$4946$426a74cc@news.free.fr>, a écrit :
Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur
le Web, je suis tombé sur cette page :
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 ?
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 06/02/2011 20:59, Nicolas George a écrit :
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 uid00(francois) gid00(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
Le 06/02/2011 20:59, Nicolas George a écrit :
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
uid00(francois) gid00(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
#---------------
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 uid00(francois) gid00(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
Bonjour,
le 06/02/2011 à 21:13, Francois Lafont a écrit dans le message <4d4f00fc$0$17749$ :
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 uid00(francois) gid00(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
Bonjour,
le 06/02/2011 à 21:13, Francois Lafont a écrit dans le message
<4d4f00fc$0$17749$426a34cc@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
uid00(francois) gid00(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
#---------------
le 06/02/2011 à 21:13, Francois Lafont a écrit dans le message <4d4f00fc$0$17749$ :
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 uid00(francois) gid00(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
Le 06/02/2011 21:00, Nicolas George a écrit :
Francois Lafont , dans le message <4d4ef783$0$4946$, a écrit :
Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur le Web, je suis tombé sur cette page :
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 ?
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 :
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
Le 06/02/2011 21:00, Nicolas George a écrit :
Francois Lafont , dans le message
<4d4ef783$0$4946$426a74cc@news.free.fr>, a écrit :
Et bien, peu de chose à vrai dire. En essayant de glaner des infos sur
le Web, je suis tombé sur cette page :
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 ?
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 :
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.
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 ?
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 :
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
Hugues
Ce cher Francois Lafont 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/]
Ce cher Francois Lafont <francois.lafont@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..
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 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.
-- Hugues Hiegel [http://www.hiegel.fr/~hugues/]
Ce cher Francois Lafont <francois.lafont@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.
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.
