Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACLs permettent à un utilisateur non root d'accorder des droits spécifiques à d'autres utilisateurs sur des fichiers qui lui appartiennent. Ceci n'est pas possible avec les droits classiques (user/group/other).
Bob qui Trolle wrote:
Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACLs permettent à un utilisateur non root d'accorder des droits
spécifiques à d'autres utilisateurs sur des fichiers qui lui
appartiennent. Ceci n'est pas possible avec les droits classiques
(user/group/other).
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACLs permettent à un utilisateur non root d'accorder des droits spécifiques à d'autres utilisateurs sur des fichiers qui lui appartiennent. Ceci n'est pas possible avec les droits classiques (user/group/other).
Fred
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
A+ Fred
Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange
Book et avec cette certification de prétendre à de nouveaux marchés
(militaires notamment).
C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas
s'en passer ;-)
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
A+ Fred
R12y
On Thu, 10 Nov 2005 08:25:09 +0100, Bob qui Trolle wrote:
les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou de RBAC, on peut autoriser certains utilisateurs non root à modifier des fichiers de configuration d'application ou du système, /etc/hosts par exemple.
Les ACL permettent aussi d'attribuer des droits impossibles à obtenir autrement, exemple, un fichier est rw pour tout le monde *sauf* pour un utilisateur qui ne peut ni le lire, ni l'écrire.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout dû à la méconnaissance, la résistance au changement, la syntaxe des commandes en ligne mal comprise, et le manque d'interface graphique permettant à un utilisateur de base d'y accéder ...
Fred wrote:
Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange
Book et avec cette certification de prétendre à de nouveaux marchés
(militaires notamment).
C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas
s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou
de RBAC, on peut autoriser certains utilisateurs non root à
modifier des fichiers de configuration d'application
ou du système, /etc/hosts par exemple.
Les ACL permettent aussi d'attribuer des droits impossibles à
obtenir autrement, exemple, un fichier est rw pour tout le
monde *sauf* pour un utilisateur qui ne peut ni le lire, ni
l'écrire.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout
dû à la méconnaissance, la résistance au changement, la syntaxe
des commandes en ligne mal comprise, et le manque d'interface
graphique permettant à un utilisateur de base d'y accéder ...
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou de RBAC, on peut autoriser certains utilisateurs non root à modifier des fichiers de configuration d'application ou du système, /etc/hosts par exemple.
Les ACL permettent aussi d'attribuer des droits impossibles à obtenir autrement, exemple, un fichier est rw pour tout le monde *sauf* pour un utilisateur qui ne peut ni le lire, ni l'écrire.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout dû à la méconnaissance, la résistance au changement, la syntaxe des commandes en ligne mal comprise, et le manque d'interface graphique permettant à un utilisateur de base d'y accéder ...
Stephane Chazelas
2005-11-10, 09:59(+01), Jean-Louis Liagre:
Fred wrote:
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou de RBAC, on peut autoriser certains utilisateurs non root à modifier des fichiers de configuration d'application ou du système, /etc/hosts par exemple.
Dans ces cas la, utiliser des groupes dediés est plus appropriés, c'est plus visible, et ca evite d'avoir a reverifier tous les fichiers quand il y a des modifications dans les utilisateurs.
Les ACL permettent aussi d'attribuer des droits impossibles à obtenir autrement, exemple, un fichier est rw pour tout le monde *sauf* pour un utilisateur qui ne peut ni le lire, ni l'écrire.
Mauvais exemple,
suffit de faire un
chown user:group file chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout dû à la méconnaissance, la résistance au changement, la syntaxe des commandes en ligne mal comprise, et le manque d'interface graphique permettant à un utilisateur de base d'y accéder ...
Et que ce n'est pas supporté partout, mal standardisé et pas assez visible, marche pas toujours tres bien avec les fs partagés et son aspect decentralisé a ses contraintes. A moins d'avoir des besoins tres specifiques, le systeme user/group est le plus souvent suffisant.
Le principal interet, comme le soulignait un autre contributeur est quand un utilisateur non-root veut partager des fichiers, mais pas avec tout le monde, ou en tout cas pas forcement avec tous les membres d'un groupe dont il ne peut pas changer la liste.
-- Stéphane
2005-11-10, 09:59(+01), Jean-Louis Liagre:
Fred wrote:
Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange
Book et avec cette certification de prétendre à de nouveaux marchés
(militaires notamment).
C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas
s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou
de RBAC, on peut autoriser certains utilisateurs non root à
modifier des fichiers de configuration d'application
ou du système, /etc/hosts par exemple.
Dans ces cas la, utiliser des groupes dediés est plus
appropriés, c'est plus visible, et ca evite d'avoir a reverifier
tous les fichiers quand il y a des modifications dans les
utilisateurs.
Les ACL permettent aussi d'attribuer des droits impossibles à
obtenir autrement, exemple, un fichier est rw pour tout le
monde *sauf* pour un utilisateur qui ne peut ni le lire, ni
l'écrire.
Mauvais exemple,
suffit de faire un
chown user:group file
chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un
group ou il n'y a que l'utilisateur.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout
dû à la méconnaissance, la résistance au changement, la syntaxe
des commandes en ligne mal comprise, et le manque d'interface
graphique permettant à un utilisateur de base d'y accéder ...
Et que ce n'est pas supporté partout, mal standardisé et pas
assez visible, marche pas toujours tres bien avec les fs
partagés et son aspect decentralisé a ses contraintes. A
moins d'avoir des besoins tres specifiques, le systeme
user/group est le plus souvent suffisant.
Le principal interet, comme le soulignait un autre contributeur
est quand un utilisateur non-root veut partager des fichiers,
mais pas avec tout le monde, ou en tout cas pas forcement avec
tous les membres d'un groupe dont il ne peut pas changer la
liste.
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Oui, bon, ok, ça ressemble à un troll.
Les ACL permettent surtout d'obtenir la certification B3 de l'Orange Book et avec cette certification de prétendre à de nouveaux marchés (militaires notamment). C'est un peu comme le Bac, on ne s'en sert jamais mais on ne peut pas s'en passer ;-)
Je m'en sert beaucoup et depuis longtemps, c'est très pratique.
Les ACL permettent d'éviter la mise en oeuvre de sudo ou de RBAC, on peut autoriser certains utilisateurs non root à modifier des fichiers de configuration d'application ou du système, /etc/hosts par exemple.
Dans ces cas la, utiliser des groupes dediés est plus appropriés, c'est plus visible, et ca evite d'avoir a reverifier tous les fichiers quand il y a des modifications dans les utilisateurs.
Les ACL permettent aussi d'attribuer des droits impossibles à obtenir autrement, exemple, un fichier est rw pour tout le monde *sauf* pour un utilisateur qui ne peut ni le lire, ni l'écrire.
Mauvais exemple,
suffit de faire un
chown user:group file chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
C'est vrai que c'est peu utilisé, mais je crois que c'est surtout dû à la méconnaissance, la résistance au changement, la syntaxe des commandes en ligne mal comprise, et le manque d'interface graphique permettant à un utilisateur de base d'y accéder ...
Et que ce n'est pas supporté partout, mal standardisé et pas assez visible, marche pas toujours tres bien avec les fs partagés et son aspect decentralisé a ses contraintes. A moins d'avoir des besoins tres specifiques, le systeme user/group est le plus souvent suffisant.
Le principal interet, comme le soulignait un autre contributeur est quand un utilisateur non-root veut partager des fichiers, mais pas avec tout le monde, ou en tout cas pas forcement avec tous les membres d'un groupe dont il ne peut pas changer la liste.
-- Stéphane
Nicolas Le Scouarnec
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
On peut s'en sortir avec user/group/other, mais il faut alors creer un certains nombre de groupes. D'une part, la création d'une groupe nécéssite l'intervention de l'utilisateur root. Et d'autre part, un utilisateur est limité a un certains nombre de groupes (16), donc il faut creer des groupes d'utilisateur qui ont un sens au niveau de l'organisation , et ensuite utiliser les acl en donnant les acces aux groupes et aux utilisateurs.
L'exemple que j'ai sous la main, c'est proteger l'accès a ses fichiers "*.php" tout en laissant www (apache) les lire, il suffit de faire: chmod 700 intra_html setfacl -m u:www:--x intra_html
On peut le faire sans etre root. Alors qu'autrement, il faut faire intervenir root, puisque si on appartient pas au groupe www, ca ne passe pas.
$chgrp spamd ftp chgrp: you are not a member of group spamd
Malheureusement, les ACL, ca passe mal via NFS... Surtout quand l'OS est différent de tous les cotés. Mais comme les droits unix ca passe déja mal via NFS quand l'OS est Windows en face...
Et l'autre défaut, c'est qu'en faisant ls -l , on n'a pas les acl, il faut faire getfacl intra_html
-- Nicolas Le Scouarnec
Je me demandais dans quel cas pratique mettant en scène un unix, des
logiciels classiques et une organisation humaine à peu près rationelle
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
On peut s'en sortir avec user/group/other, mais il faut alors creer un
certains nombre de groupes. D'une part, la création d'une groupe
nécéssite l'intervention de l'utilisateur root. Et d'autre part, un
utilisateur est limité a un certains nombre de groupes (16), donc il
faut creer des groupes d'utilisateur qui ont un sens au niveau de
l'organisation , et ensuite utiliser les acl en donnant les acces aux
groupes et aux utilisateurs.
L'exemple que j'ai sous la main, c'est proteger l'accès a ses fichiers
"*.php" tout en laissant www (apache) les lire, il suffit de faire:
chmod 700 intra_html
setfacl -m u:www:--x intra_html
On peut le faire sans etre root. Alors qu'autrement, il faut faire
intervenir root, puisque si on appartient pas au groupe www, ca ne
passe pas.
$chgrp spamd ftp
chgrp: you are not a member of group spamd
Malheureusement, les ACL, ca passe mal via NFS... Surtout quand l'OS
est différent de tous les cotés. Mais comme les droits unix ca passe
déja mal via NFS quand l'OS est Windows en face...
Et l'autre défaut, c'est qu'en faisant ls -l , on n'a pas les acl, il
faut faire getfacl intra_html
Je me demandais dans quel cas pratique mettant en scène un unix, des logiciels classiques et une organisation humaine à peu près rationelle les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
On peut s'en sortir avec user/group/other, mais il faut alors creer un certains nombre de groupes. D'une part, la création d'une groupe nécéssite l'intervention de l'utilisateur root. Et d'autre part, un utilisateur est limité a un certains nombre de groupes (16), donc il faut creer des groupes d'utilisateur qui ont un sens au niveau de l'organisation , et ensuite utiliser les acl en donnant les acces aux groupes et aux utilisateurs.
L'exemple que j'ai sous la main, c'est proteger l'accès a ses fichiers "*.php" tout en laissant www (apache) les lire, il suffit de faire: chmod 700 intra_html setfacl -m u:www:--x intra_html
On peut le faire sans etre root. Alors qu'autrement, il faut faire intervenir root, puisque si on appartient pas au groupe www, ca ne passe pas.
$chgrp spamd ftp chgrp: you are not a member of group spamd
Malheureusement, les ACL, ca passe mal via NFS... Surtout quand l'OS est différent de tous les cotés. Mais comme les droits unix ca passe déja mal via NFS quand l'OS est Windows en face...
Et l'autre défaut, c'est qu'en faisant ls -l , on n'a pas les acl, il faut faire getfacl intra_html
-- Nicolas Le Scouarnec
Stephane Chazelas
On Thu, 10 Nov 2005 09:49:29 +0100, R12y wrote:
On Thu, 10 Nov 2005 08:25:09 +0100, Bob qui Trolle wrote:
les ACLs permettaient de faire ce que les droits fichiers unix ne permettaient pas de faire.
Mauvais exemple aussi, il suffisait de faire un chmod 711 ~ chmod og= ~/* ~/.[!.]* ~/..?* chmod 755 ~/public_html # en zsh: chmod og= ~/^public_html(D)
Pour que ~/public_html soit accessible, mais que ni ~ ni les fichiers qu'il contient ne soient lisibles.
-- Stephane
On Thu, 10 Nov 2005 09:49:29 +0100, R12y wrote:
On Thu, 10 Nov 2005 08:25:09 +0100, Bob qui Trolle wrote:
les ACLs permettaient de faire ce que les droits fichiers unix ne
permettaient pas de faire.
Mauvais exemple aussi, il suffisait de faire un
chmod 711 ~
chmod og= ~/* ~/.[!.]* ~/..?*
chmod 755 ~/public_html
# en zsh: chmod og= ~/^public_html(D)
Pour que ~/public_html soit accessible, mais que ni ~ ni les
fichiers qu'il contient ne soient lisibles.
Mauvais exemple aussi, il suffisait de faire un chmod 711 ~ chmod og= ~/* ~/.[!.]* ~/..?* chmod 755 ~/public_html # en zsh: chmod og= ~/^public_html(D)
Pour que ~/public_html soit accessible, mais que ni ~ ni les fichiers qu'il contient ne soient lisibles.
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
suffit de faire un
chown user:group file chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre groupe, il me semble, non ?
Stephane Chazelas wrote in message
<slrndn64gd.5t4.stephane.chazelas@spam.is.invalid>:
suffit de faire un
chown user:group file
chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un
group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre
groupe, il me semble, non ?
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre groupe, il me semble, non ?
Stephane Chazelas
On Thu, 10 Nov 2005 12:17:54 +0000 (UTC), Nicolas George wrote:
Stephane Chazelas wrote in message :
suffit de faire un
chown user:group file chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre groupe, il me semble, non ?
Non.
(au moins sous Solaris et Linux et d'apres SUSv3).
3.166 File Group Class
The property of a file indicating access permissions for a process related to the group identification of a process. A process is in the file group class of a file if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. Other members of the class may be implementation-defined.
4.4: [access granted if:] Access shall be granted if an alternate access control mechanism is not enabled and the requested access permission bit is set for the class (file owner class, file group class, or file other class) to which the process belongs, or if an alternate access control mechanism is enabled and it allows the requested access; otherwise, access shall be denied.
Donc, un processus de "l'utilisateur" sera dans la file group class de "file" et n'aura donc pas acces au fichier, puisqu'il fait partie de "group" et qu'il n'est pas "user".
-- Stephane
On Thu, 10 Nov 2005 12:17:54 +0000 (UTC), Nicolas George wrote:
Stephane Chazelas wrote in message
<slrndn64gd.5t4.stephane.chazelas@spam.is.invalid>:
suffit de faire un
chown user:group file
chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un
group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre
groupe, il me semble, non ?
Non.
(au moins sous Solaris et Linux et d'apres SUSv3).
3.166 File Group Class
The property of a file indicating access permissions for a
process related to the group identification of a process. A
process is in the file group class of a file if the process is
not in the file owner class and if the effective group ID or
one of the supplementary group IDs of the process matches the
group ID associated with the file. Other members of the class
may be implementation-defined.
4.4: [access granted if:]
Access shall be granted if an alternate access control
mechanism is not enabled and the requested access permission
bit is set for the class (file owner class, file group class,
or file other class) to which the process belongs, or if an
alternate access control mechanism is enabled and it allows the
requested access; otherwise, access shall be denied.
Donc, un processus de "l'utilisateur" sera dans la file group
class de "file" et n'aura donc pas acces au fichier, puisqu'il
fait partie de "group" et qu'il n'est pas "user".
On Thu, 10 Nov 2005 12:17:54 +0000 (UTC), Nicolas George wrote:
Stephane Chazelas wrote in message :
suffit de faire un
chown user:group file chmod 606 file
ou user n'est pas l'utilisateur en question, et group est un group ou il n'y a que l'utilisateur.
Ça suppose que l'utilisateur en question ne fasse jamais partie d'un autre groupe, il me semble, non ?
Non.
(au moins sous Solaris et Linux et d'apres SUSv3).
3.166 File Group Class
The property of a file indicating access permissions for a process related to the group identification of a process. A process is in the file group class of a file if the process is not in the file owner class and if the effective group ID or one of the supplementary group IDs of the process matches the group ID associated with the file. Other members of the class may be implementation-defined.
4.4: [access granted if:] Access shall be granted if an alternate access control mechanism is not enabled and the requested access permission bit is set for the class (file owner class, file group class, or file other class) to which the process belongs, or if an alternate access control mechanism is enabled and it allows the requested access; otherwise, access shall be denied.
Donc, un processus de "l'utilisateur" sera dans la file group class de "file" et n'aura donc pas acces au fichier, puisqu'il fait partie de "group" et qu'il n'est pas "user".
-- Stephane
Nicolas George
Stephane Chazelas wrote in message :
Donc, un processus de "l'utilisateur" sera dans la file group class de "file" et n'aura donc pas acces au fichier, puisqu'il fait partie de "group" et qu'il n'est pas "user".
En fait, j'étais resté sur l'impression qu'un processus appartenant à plusieurs groupes pouvait commuter entre ces différents groupes (au sens : faire passer son GID à celui d'un des groupes supplémentaires, et abandonner des groupes supplémentaires), mais apparemment je m'étais trompé.
Stephane Chazelas wrote in message
<slrndn6j15.2ta.stephane_chazelas@duey.spider.com>:
Donc, un processus de "l'utilisateur" sera dans la file group
class de "file" et n'aura donc pas acces au fichier, puisqu'il
fait partie de "group" et qu'il n'est pas "user".
En fait, j'étais resté sur l'impression qu'un processus appartenant à
plusieurs groupes pouvait commuter entre ces différents groupes (au sens :
faire passer son GID à celui d'un des groupes supplémentaires, et abandonner
des groupes supplémentaires), mais apparemment je m'étais trompé.
Donc, un processus de "l'utilisateur" sera dans la file group class de "file" et n'aura donc pas acces au fichier, puisqu'il fait partie de "group" et qu'il n'est pas "user".
En fait, j'étais resté sur l'impression qu'un processus appartenant à plusieurs groupes pouvait commuter entre ces différents groupes (au sens : faire passer son GID à celui d'un des groupes supplémentaires, et abandonner des groupes supplémentaires), mais apparemment je m'étais trompé.
