Un utilisateur Windows peut écraser les permissions ACL NFSv4/Solaris des fichiers sur un partage CIFS/SMB (s'octroyant un accès complet), comment puis-je empêcher cela ?

Question

Un utilisateur Windows peut écraser les permissions ACL NFSv4/Solaris des fichiers sur un partage CIFS/SMB (s'octroyant un accès complet), comment puis-je empêcher cela ?

Demandé el 21 de Mars, 2016: Quand la question a-t-elle été
1505 affichage: Nombre de visites la question a
2 Réponses: Nombre de réponses aux questions
Résolu: Situation réelle de la question

J'ai configuré le partage de fichiers SMB/CIFS sur un serveur OmniOS avec le module noyau Solaris qui utilise les ACL NFSv4 qui devraient fonctionner correctement avec les clients Windows.

Je veux créer un répertoire partagé avec les objectifs suivants : un utilisateur (disons alice ) doit pouvoir créer et modifier des fichiers, mais pas les supprimer. La création de sous-répertoires doit également être empêchée. L'accès en lecture doit être autorisé.

J'ai essayé l'ACL suivante, qui fonctionne en gros :

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

Mais si alice voit le Sécurité des fichiers nouvellement ajoutés dans l'Explorateur Windows, elle peut s'octroyer des droits d'accès complets et supprimer le fichier par la suite, même si elle ne dispose pas d'un droit d'accès. Co droits.

Comment expliquer ce comportement ? Et comment puis-je le changer pour que les ACL ne puissent pas être modifiées ?

Edit : Sortie de ls semble être normal :

# /usr/bin/ls -v
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    0:user:root:read_data/write_data/append_data/read_xattr/write_xattr
        /execute/delete_child/read_attributes/write_attributes/delete
        /read_acl/write_acl/write_owner/synchronize:inherited:allow
    1:user:alice:read_data/write_data/append_data/read_xattr
        /write_xattr/execute/read_attributes/write_attributes/read_acl
        /synchronize:inherited:allow

# /usr/bin/ls -V
total 1
-rwx------+  1 alice staff          3 2016-03-21 test.txt
    user:root:rwxpdDaARWcCos:------I:allow
    user:alice:rwxp--aARWc--s:------I:allow

Sortie de ls pour le répertoire lui-même :

# /usr/bin/ls -Vd
drwx------+  3 root     root           4 2016-03-21 .
 user:root:rwxpdDaARWcCos:fd-----:allow
user:alice:rwx---a-R-c--s:-------:allow
user:alice:rwxp--aARWc--s:f-i----:allow

# /usr/bin/ls -vd
drwx------+  3 root     root           4 2016-03-21 .
    0:user:root:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /delete_child/read_attributes/write_attributes/delete/read_acl
        /write_acl/write_owner/synchronize:file_inherit/dir_inherit:allow
    1:user:alice:list_directory/read_data/add_file/write_data
        /read_xattr/execute/read_attributes/read_acl/synchronize:allow
    2:user:alice:list_directory/read_data/add_file/write_data
        /add_subdirectory/append_data/read_xattr/write_xattr/execute
        /read_attributes/write_attributes/read_acl/synchronize
        :file_inherit/inherit_only:allow

Le système de fichiers du partage est ZFS. Les propriétés par défaut les plus intéressantes sont les suivantes :

NAME        PROPERTY        VALUE          SOURCE
pool/share  type            filesystem     -
pool/share  compression     lz4            inherited from pool
pool/share  atime           off            local
pool/share  aclmode         restricted     local
pool/share  aclinherit      passthrough    local
pool/share  version         5              -
pool/share  utf8only        on             -
pool/share  normalization   formD          -
pool/share  casesensitivity insensitive    -
pool/share  nbmand          on             local
pool/share  sharesmb        name=testshare local

Les autorisations de partage CIFS sont définies de manière à permettre à tout le monde un accès complet, donc seule l'autorisation de fichier devrait s'appliquer.

Mise à jour :

Ce fil est très similaire à mon problème, bien que la solution consistant à réduire les ACL en /pool/share/.zfs/shares/testshare a modify_set pour tout le monde (ou refuser aux utilisateurs des droits de suppression spécifiques) ne semble pas fonctionner dans mon cas et je ne sais pas pourquoi.

Demandé el 21 de Mars, 2016 par user121391

Answer 1

2 Réponses

Answer 2

1voto

Almad Points 2091

IMHO tout devient vraiment confus si vous enlevez les acls triviaux pour user, group, everyone. Des choses à considérer :

En cas de refus d'autorisation ou lorsqu'une autorisation d'accès à un fichier est manquante, le sous-système de privilèges détermine quelle demande d'accès est accordée pour le propriétaire du fichier ou pour le superutilisateur. Ce mécanisme empêche les propriétaires de fichiers d'être bloqués et permet au superutilisateur de modifier les fichiers à des fins de récupération.
Les listes de contrôle d'accès basées sur le projet POSIX utilisent une seule entrée pour définir les autorisations autorisées et celles qui sont refusées. Le nouveau modèle ACL comporte deux types d'ACE qui affectent le contrôle d'accès : ALLOW et DENY
Le propriétaire d'un fichier se voit accorder la permission write_acl sans condition, même si cette permission est explicitement refusée.
Si vous modifiez les permissions du fichier, la LCA du fichier est mise à jour en conséquence. En outre, si vous supprimez une liste de contrôle d'accès non triviale qui permettait à un utilisateur d'accéder à un fichier ou à un répertoire, cet utilisateur peut toujours avoir accès au fichier ou au répertoire en raison des bits d'autorisation du fichier ou du répertoire qui permettent l'accès à un groupe ou à tout le monde.

Mon approche consiste donc à modifier les acls triviales en fonction des besoins (utilisation du mode deny) et à ajouter des acls non triviales pour tous les cas d'utilisation particuliers. Gardez cela à l'esprit également :

Une fois qu'une autorisation a été accordée, elle ne peut pas être refusée par une entrée de refus ACL ultérieure dans le même ensemble d'autorisations ACL.

Je n'ai aucune idée de ce qu'est OmniOS, mais ces documents m'ont aidé à comprendre NFS ACL. Nous utilisons Solaris avec ZFS https://docs.oracle.com/cd/E53394_01/html/E54801/ftyxi.html#scrolltoc

Répondu el 23 de Mars, 2016 par Almad (2091 Points )

Answer 3

1voto

user121391 Points 2362

Après avoir ignoré ce problème pendant une semaine, il fonctionne soudainement... Je ne sais pas ce qui l'a provoqué, mais il fonctionne... J'ai essayé la suggestion de ce blog mais l'a modifié pour inclure AW comme des droits. Puis je l'ai testé à nouveau, cette fois uniquement avec mes anciennes règles de refus (en écrasant complètement les nouvelles), ce qui a également fonctionné. Enfin, j'ai utilisé les tout premiers paramètres de ma propre question, qui n'ont jamais fonctionné, mais qui fonctionnent maintenant.

Après quelques tests supplémentaires, je pense que c'est parce que le service SMB n'a pas été redémarré avant et que les ACL de partage n'ont pas été reconnues correctement. Les modifier était le seul moyen de rétablir l'ancien (et mauvais) comportement.

Donc, pour l'avenir, la solution est de définir les permissions normales sur les fichiers eux-mêmes, et de ne pas permettre à Co les permissions au niveau du partage :

Appliquez les règles ACL suivantes au répertoire et (héritées) à tous les fichiers nouvellement créés :

/usr/bin/chmod A=\
user:root:rwxpdDaARWcCos:fd-----:allow,\    # root has full access
user:alice:rwx---a-R-c--s:-------:allow,\   # dir: create files, read everything
user:alice:rwxp--aARWc--s:f-i----:allow \   # files: wpAW is needed for full file write access, everything is only inherited to files
/pool/share

Appliquez les règles ACL suivantes au répertoire de partage caché de l'ensemble de données ZFS (ceci est nécessaire pour empêcher le propriétaire de modifier les ACL, pour plus de détails voir la réponse de @embedded et le post serverfault lié) :
```
/usr/bin/chmod A=\
user:root:full_set:-------:allow,\          # root has full access
everyone@:modify_set:-------:allow \        # anyone else cannot modify permissions
/pool/share/.zfs/shares/testshare
```

Redémarrer le serveur SMB (nécessaire pour mettre à jour les ACL de partage modifiées, voir ce fil ):

svcadm restart svc:/network/smb/server:default # restart service
svcs -xv svc:/network/smb/server:default       # check if the startup date has changed

Désormais, les nouveaux fichiers peuvent être créés et écrits, mais pas supprimés et les utilisateurs de Windows ne peuvent pas non plus s'octroyer de droits supplémentaires. Cette solution fonctionne bien pour ma situation, mais je vois deux petits inconvénients :

Vous devez vous souvenir/documenter que vous avez modifié le niveau de partage, si des autorisations supplémentaires doivent être définies à l'avenir.
Il est possible qu'un utilisateur modifie le contenu des documents. Par exemple, alice peut écraser des caractères ou des lignes dans un document texte. Je pense que c'est parce que l'application que j'utilise a besoin des privilèges d'ajout et d'écriture et qu'il n'y a pas de liste de contrôle d'accès qui vérifie "écriture initiale uniquement" ou similaire.

Répondu el 4 de Avril, 2016 par user121391 (2362 Points )

Un utilisateur Windows peut écraser les permissions ACL NFSv4/Solaris des fichiers sur un partage CIFS/SMB (s'octroyant un accès complet), comment puis-je empêcher cela ?

Réponses

Questions en vedette

Top Tags

SistemesEz.com

Powered by:

Un utilisateur Windows peut écraser les permissions ACL NFSv4/Solaris des fichiers sur un partage CIFS/SMB (s'octroyant un accès complet), comment puis-je empêcher cela ?

Réponses

Questions en vedette

Top Tags

Dans notre réseau

SistemesEz.com

Powered by: