serveur NFS: bug ou incompréhension de mon coté?

[CoolRaoul]

Salut,

un pote m'a fait cadeau d'un raspberry et je fais un peu joujou avec.

J'ai exporté en NFS un des partages du Syno. Dans ce dossier partagé je crée un sous-dossier limité (via les ACLs) à mon compte utilisateur DSM.

Je vérifie qu'un autre compte DSM ne peut pas accéder à ce dernier (connecté root en ligne de commande, su - <userlambda> puis touch <chemin du dossier> me donne bien "permission denied".

Et pourtant, à partir du raspberry, en étant connecté sur ce dernier au compte par défaut, "pi" (uid 1000) je peux accéder à ce dossier monté NFS et même y créer fichiers et sous-dossiers!

Par quelle magie le compte "pi" du raspberry dispose de plus de privileges qu'un compte local DSM?

 

[PiwiLAbruti]

Si j'ai bien compris, tu as créé le compte "pi" sur le NAS et tu t'en sers pour accéder à ton partage depuis le RPi ?

[CoolRaoul]

il y a 12 minutes, PiwiLAbruti a dit :

Si j'ai bien compris, tu as créé le compte "pi" sur le NAS et tu t'en sers pour accéder à ton partage depuis le RPi ?

Non: le compte "pi" c'est le compte par défault de la distrib raspbian sur le raspberry. Pour celui-ci j'ai l'impression que les partages du NAS accédés en NFS deviennent open bar alors que ce compte n'a pas d"équivalent sous DSM ayant le même UID.

Je n'ai pas créé de compte "pi" sur le NAS.

**EDIT**

Désolé si je ne suis pas clair, je reformule:

Dans une session shell tournant sur le PI avec le compte "pi" je peux allègrement créer/modifier/effacer des fichier sur le NAS par le montage NFS dans un dossier dont les droits ne devrait pas me le permettre.

 

Modifié le 27 janvier 2018 par CoolRaoul

[PiwiLAbruti]

Le compte "guest" du NAS est désactivé ? Si c’est le cas, c’est vraiment inquiétant.

Tu as comparé les versions de NFS utilisées sur le RPi et le NAS ?

[CoolRaoul]

Il y a 6 heures, PiwiLAbruti a dit :

Le compte "guest" du NAS est désactivé ? Si c’est le cas, c’est vraiment inquiétant.

C'est bien le cas.

Il y a 6 heures, PiwiLAbruti a dit :

Tu as comparé les versions de NFS utilisées sur le RPi et le NAS ?

La version du protocole est V4 des deux coté.

Sinon j'ai un peu avancé dans mes tests.

• Créé un compte sur le PI avec même user et UID  qu'un compte existant sur le NAS, ce dernier n'a pas accès au dossier partagé (ce qui est normal, j'ai limité les droits du répertoire à un autre compte unique)
• Crée un autre compte sur le PI avec user et UID inexistants sur le NAS: pas d'accès non plus
• Autre compte ("pi2") créé sur le PI avec même uid et même gid que "pi": toujours pas d'accès

Qu'est-ce qui peut bien faire que le compte "pi" du PI soit capable d'outrepasser les droits par NFS?

Via ses groupes?

pi@rasp.local> id
uid=1000(pi) gid=1000(pi) groups=1000(pi),4(adm),20(dialout),24(cdrom),27(sudo),29(audio),44(video),46(plugdev),60(games),100(users),101(input),108(netdev),997(gpio),998(i2c),999(spi)

 

 

 

Modifié le 28 janvier 2018 par CoolRaoul

[CoolRaoul]

Trouvé! (par itérations): c'est l'appartenance au groupe "101" ("input" sur le pi, "administrators" sur le NAS) qui permet l'accès. (Les droits que j'avais donné au dossier du dossier était ouvert aux administrateurs en plus du compte isolé)

Faudrait que je trouve un moyen de maîtriser plus finement le mappage des groupes sur NFS.

 

[PiwiLAbruti]

Très intéressant.

Ça voudrait dire qu'on peut accéder à n'importe quel partage du NAS du moment qu'on utilise un compte appartenant à un groupe dont le 'guid' est commun avec un groupe du NAS ?

[CoolRaoul]

Il y a 2 heures, PiwiLAbruti a dit :

Ça voudrait dire qu'on peut accéder à n'importe quel partage du NAS du moment qu'on utilise un compte appartenant à un groupe dont le 'guid' est commun avec un groupe du NAS ?

Si on veux être plus rigoureux c'est pas "n'importe quel partage" et le "on" ne signifie pas n'importe quel compte client non plus:

• ne s'applique qu'aux partages pour lesquels on a explicitement spécifié des entrées d'autorisation NFS.
• Uniquement à partir de machines client NFS qui  "matchent" une des entrées autorisations définies ci dessus.
• et pour ces dernières, seulement à partir des comptes faisant partie d'un groupe dont la valeur de GID  est 101 (administrateurs sur le NAS).
• important: c'est le comportement normal de NFS pour les partages dont la sécurité est de type "sys". Dans ce cas, l'UID du user source et la liste des GIDS de ses groupe sont pris en compte tels quels sur le NAS pour autoriser ou nom l'accès demandé à la ressource et chacun des fichiers/répertoires qu'elle contient (ce mapping serait configurable via le mécanisme idmapd mais il semble impossible de l'activer complètement sous DSM)

Techniquement il est possible de désactiver le droit d'accès à un partage au groupe "administrateurs" (droit attribué par défaut). L'inconvénient est que ça implique sa non visibilité dans filestation pour les compte administrateurs ("admin" y compris) . Ca complique la gestion des droits du partage.

Contournement: créer un groupe spécifiquement destiné à cet usage (administration du stockage) dont le compte "admin" est membre (éventuellement unique). Donner l’accès R/W  aux partages à ce groupe à la place du groupe "administrateurs".

D'après ce que j'ai lu, ceci ne s'applique plus dans le cas ou on est capable de choisir l'authentification "Kerberos" pour le partage NFS, car dans ce cas on devient capable d'ajuster les mappings UID et GID.