[troll] a quoi servent les ACLs ?

2005-11-10, 13:46(+00), Nicolas George:

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é.

Oui, un process a un effective gid et des gid supplementaires.
Ca s'herite de pere en fils et c'est initialisé par login (ou
su, sudo, xdm...) qui le tiens d'/etc/passwd et /etc/group (ou
equivalents).

Il n'y a que les process d'eid 0 qui peuvent s'ajouter des
groupes ou changer leur egid. (login est setuid 0 justement et
fait un setuid(uid-de-lutilisateur) apres avoir fait le setgid
et ajouté les groupes supplementaires).

--
Stéphane

Stephane Chazelas wrote:

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.

mais un fichier n'appartient qu'à un groupe, il faudrait créer
un groupe par fichier si l'on souhaite le même niveau de
granularité que ce que permettent les ACL.

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 lourd, il faut créer un groupe par utilisateur, et seul
root à le droit de faire ça.

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.

C'est exactement ce que j'appelle la résistance au changement ...

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.

C'est en effet un bon exemple.

Nicolas Le Scouarnec wrote:

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 vois aussi un autre problème : j'ai l'impression qu'on ne peut pas
prédire avec des ACLs à la création du processus[*] le temps maximal que
prend l'évaluation du droit d'accès sur un objet arbitraire, ce qui est
possible avec le système des droits unix.

[*] avec quelques réserves en cas de manipulation des groupes pendant la
durée de vie du processus et selon le système...

On Thu, 10 Nov 2005 23:40:59 +0100, Jean-Louis Liagre wrote:
[...]

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.

mais un fichier n'appartient qu'à un groupe, il faudrait créer
un groupe par fichier si l'on souhaite le même niveau de
granularité que ce que permettent les ACL.

Dans le que tu decris plus haut, mois, je vois plutot des roles.
Faire une decoupe par fichier ne fait pas beaucoup de sens et
deviendrait assez lourd a gerer. Dans /etc/group, tu definis des
roles, un groupe par role. Et tu assignes un role a un fichier.
C'est tout de meme plus propre que d'assigner un user specifique
a un fichier. Si ce user s'en va ou est muté sur un autre role,
il faut revoir tous les fichiers au lieu de juste revoir
/etc/group.

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 lourd, il faut créer un groupe par utilisateur, et seul
root à le droit de faire ça.

Beaucoup de setups ont maintenant un gid par uid, c'est ce
qui permet le plus de flexibilité.

Quant au fait que seul root peut faire ca, on est d'accord que
c'est probablement le principal avantage des ACL.

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.

C'est exactement ce que j'appelle la résistance au changement ...

Pas moi. Je trouve les ACLs lourdes et inadaptées dans la
plupart des cas. Je ne me souviens pas d'avoir rencontré personnellement
de cas ou le owner/group/other system etait insuffisant.


KISS.
Stephane

Stephane Chazelas wrote:

On Thu, 10 Nov 2005 23:40:59 +0100, Jean-Louis Liagre wrote:
[...]

C'est lourd, il faut créer un groupe par utilisateur, et seul
root à le droit de faire ça.

Beaucoup de setups ont maintenant un gid par uid, c'est ce
qui permet le plus de flexibilité.

Quant au fait que seul root peut faire ca, on est d'accord que
c'est probablement le principal avantage des ACL.

C'est un avantage qu'il ne faut pas négliger.

La gestion de la confidentialité des fichiers n'est pas un besoin
limité aux militaires, les ACL permettent au propriétaire d'un
fichier d'accorder ou de retirer des droits sur ce fichier avec
une flexibilité totale et sans dépendre de la disponibilité d'un
administrateur.

-jll

Nicolas Le Scouarnec <root@india.ath.cx.nospam.invalid> 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.

Je ne comprends pas bien ce que vous dites, mais ...

Question con.
Tu fais comment un "inherit" avec les droits Unix classics ?
Tu peux faire un umask qui résiste à un "cp -pr" ?

Et si tu as besoins de 3 niveaux de granularité, genre un groupe en rw-,
un groupe en r-- et un en --- ?
(j'ai pas dit un user en rw-, mais bien un groupe)

Sinon les acl (sur mon système dumoins) permettent plus que juste rwx.
Mais j'en ai pas encore eu le besoins, c'est vrais.
genre append, add_file ou add_subdirectory.

setfacl -m u:www:--x intra_html

Gh ?
pas de setfacl mais chmod chez moi.
mais c'est pas (pas encore ?) parfait.

Et l'autre défaut, c'est qu'en faisant ls -l , on n'a pas les acl, il
faut faire getfacl intra_html

reGh ?
Ah, oui, encore ce foutu mac qui fait rien comme les autres ...

[mmac110:~> man ls |grep -i acl
-e Print the Access Control List (ACL) associated with ...

Sur ce coup là, Apple a eu raison de pas faire pareil, c'est bien
pratique le -le
--
Plus je connais linux, plus j'aime le mac.
Nicolas