Re: Re: ACL Posix sur NFS
> Bonjour,
Bonjour
> Julien Valroff a écrit :
>
> Le vendredi 20 mai 2005 à 19:40 +0200, Tony GALMICHE a écrit :
>
> ma connaissance, la meilleure façon de faire des
> partages avec le support des acl est encore d'utiliser
> samba, même s'il n'y aucun poste Windows sur le
> réseau.
>
>
> C'est la réponse que je craignais ! Je n'ai aucune envie de
> mettre en
> place ce protocole auquel je n'ai toujours rien compris et qui
> serait
> sur-dimensionné pour mon réseau.
>
>
> Je ne comprend pas ce que tu entends par sur-dimensionné. Samba
> fonctionne très bien même pour deux postes.
>
> A partir du moment que tu veux avoir le support des acl, cela signifie
> que tu demandes des fonctionnalités avancées.
[...]
Fonctionnalités avancées si l'on veut, je souhaite juste pouvoir avoir
sur mon serveur de fichiers un répertoire sur lequel des utilisateurs
définis peuvent avoir tous les droits sur tous les fichiers afin de
faciliter les échanges de documents, le travail collaboratif etc. Ca ne
me parait pas être si avancé que cela...
Quand je dis que Samba est sur-dimensionné, c'est surtout que j'ai déjà
des exports NFS en place, que je ne souhaite pas modifier, et ajouter un
serveur Samba me paraît beaucoup pour si peu : 2 protocoles pour le
simple partage de fichiers, tu avoueras que c'est lourd. Mais je
rappelle que c'est un pont de vue personnel, et que je suis tout à fait
d'accord avec toi quand tu parles des possibilités de Samba face à
celles de NFS (mais j'avoue être assez ignare dans les deux cas).
Et puis, ça tourne au défi personnel, je n'aime pas m'arrêter en si bon
chemin.
> Je ne vois pas trop comment tu peux partager des fichiers avec shfs,
> mais si tu trouves ça m'intéresse juste par curiosité :-)
Je cherche aussi ;-) Je n'ai pas cherché plus loin car j'avance peu à
peu avec NFS v3 (!!) : en fait, si j'ai bien compris mes différentes
lectures, NFS v3 ne supporte pas les ACL Posix, mais puisque celles-ci
sont définies sur le serveur, ça ne pose que quelques problèmes
pratiques - qui empêchent tout de même leur utilisation, mais cela ne
tient qu'à quelques petites rustines :
http://client.linux-nfs.org/Linux-2.6.x/2.6.12-rc3/
et en particulier
http://client.linux-nfs.org/Linux-2.6.x/2.6.12-rc3/linux-2.6.12-28-nfsacl_umask_client_workaround.dif
Pour expliquer le problème, voici un exemple :
J'ai un répertoire /home/partage avec les droits suivants :
#ll -d /home/partage/
drwxrwsr-x+ 2 root users 4096 2005-05-21 18:01 /home/partage/
et les ACL posix suivantes :
#getfacl /home/partage/
getfacl: Removing leading '/' from absolute path names
# file: home/partage
# owner: root
# group: users
user::rwx
user:toto:rwx
user:titi:rwx
group::r-x
mask::rwx
other::r-x
default:user::rwx
default:user:toto:rwx
default:user:titi:rwx
default:group::r-x
default:mask::rwx
default:other::r-x
Donc dans ce cas, en local, tout fonctionne : toto et titi peuvent
créer, modifier, supprimer des fichiers (même ceux dont ils ne sont pas
propriétaires).
Lorsque, par exemple, toto créé un fichier en local, voilà les droits :
$touch test.acl
$ll test.acl
-rw-rw-r--+ 1 toto users 0 2005-05-21 18:33 test.acl
Et tout va pour le mieux dans le meilleur des mondes.
Par contre, à distance, lorsque toto créé un fichier à travers le
montage NFS (que ce soit en console ou avec nautilus) et que je vérifie
les droits sur le serveur :
#ll test2.acl
-rw-r--r--+ 1 toto users 0 2005-05-21 18:34 test2.acl
Les umask sont pourtant les mêmes sur le serveur et le client (0022) et
ne permettent donc pas d'avoir un mask suffisant :
#getfacl test2.acl
# file: test2.acl
# owner: toto
# group: users
user::rw-
user:toto:rwx #effective:r--
user:titi:rwx #effective:r--
group::r-x #effective:r--
mask::r--
other::r--
Je vais donc compilé un noyau 2.6.12-rc4 patché sur une machine de tests
et vérifier que tout fonctionne.
J'espère avoir bien compris, corrigez-moi si je me trompe dans mes
théories ;-)
@++
Julien
Reply to: