Comment umask affecte-t-il les ACL?


12

Quelqu'un peut-il m'expliquer comment umaskaffecte le masque par défaut des fichiers nouvellement créés si les ACL sont activées? Existe-t-il une documentation à ce sujet?

Exemple:

$ mkdir test_dir && cd test_dir
$ setfacl -m d:someuser:rwx -m u:someuser:rwx .  # give access to some user
$ getfacl .
# file: .
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx
group::---
mask::rwx
other::---
default:user::rwx
default:user:someuser:rwx
default:group::---
default:mask::rwx
default:other::---
$ umask # show my umask
077
$ echo "main(){}" > x.c # minimal C program
$ make x # build it
cc     x.c   -o x
$ getfacl x
# file: x
# owner: myUsername
# group: myGroup
user::rwx
user:someuser:rwx           #effective:rw-
group::---
mask::rw-
other::---

Je m'attendrais mask:rwx. En fait, après avoir défini umaskpar exemple, 027j'obtiens le comportement attendu.


Avec un umask de 077, vous obtiendrez un mask::rw-. Mais ce n'est pas vraiment votre question, n'est-ce pas?
slm

@slm Cela fait partie de ma question. Je veux savoir comment le masque des nouveaux fichiers dépend du umask. J'ai été assez surpris qu'avec 077 j'obtiens mask::rw-et non mask::rwxquel était le masque par défaut du répertoire.
jofel

OK, je mets à jour ma réponse maintenant avec des exemples qui devraient aider à clarifier les choses. Donnez-moi quelques minutes.
slm

Cette question est étroitement liée.
jofel

Réponses:


10

J'ai trouvé cet exemple, intitulé: ACL et MASK sous linux . Dans cet article, les exemples suivants sont présentés, ce qui, à mon avis, aide à comprendre comment les ACL et umaskinteragissent les uns avec les autres.

Contexte

Lorsqu'un fichier est créé sur un système Linux, les autorisations par défaut 0666sont appliquées tandis que lorsqu'un répertoire est créé, les autorisations par défaut 0777sont appliquées.

exemple 1 - fichier

Supposons que nous réglions notre umask sur 077 et que nous touchions un fichier. Nous pouvons utiliser stracepour voir ce qui se passe réellement lorsque nous faisons cela:

$ umask 077; strace -eopen touch testfile 2>&1 | tail -1; ls -l testfile
open("testfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3
-rw-------. 1 root root 0 Sep 4 15:25 testfile

Dans cet exemple, nous pouvons voir que l'appel système open()est effectué avec les autorisations 0666, mais lorsque le umask 077est ensuite appliqué par le noyau, les autorisations suivantes sont supprimées ( ---rwxrwx) et nous nous retrouvons avec rw-------aka 0600.

exemple - 2 répertoire

Le même concept peut être appliqué aux répertoires, sauf qu'au lieu des autorisations par défaut étant 0666, elles sont 0777.

$ umask 022; strace -emkdir mkdir testdir; ls -ld testdir
mkdir("testdir", 0777)                  = 0
drwxr-xr-x 2 saml saml 4096 Jul  9 10:55 testdir

Cette fois, nous utilisons la mkdircommande. La mkdircommande a ensuite appelé l'appel système mkdir(). Dans l'exemple ci-dessus, nous pouvons voir que la mkdircommande a appelé l' mkdir()appel système avec les autorisations par défaut 0777( rwxrwxrwx). Cette fois avec un umask des 022autorisations suivantes sont supprimées ( ----w--w-), nous nous retrouvons donc avec 0755 ( rwxr-xr-x) lors de la création des répertoires.

exemple 3 (Application de l'ACL par défaut)

Créons maintenant un répertoire et montrons ce qui se passe lorsque l'ACL par défaut lui est appliquée avec un fichier à l'intérieur.

$ mkdir acldir
$ sudo strace -s 128 -fvTttto luv setfacl -m d:u:nginx:rwx,u:nginx:rwx acldir

$ getfacl --all-effective acldir
# file: acldir
# owner: saml
# group: saml
user::rwx
user:nginx:rwx          #effective:rwx
group::r-x          #effective:r-x
mask::rwx
other::r-x
default:user::rwx
default:user:nginx:rwx      #effective:rwx
default:group::r-x      #effective:r-x
default:mask::rwx
default:other::r-x

Créons maintenant le fichier aclfile:

$ strace -s 128 -fvTttto luvly touch acldir/aclfile

# view the results of this command in the log file "luvly"
$ less luvly

Obtenez maintenant les autorisations du fichier nouvellement créé:

$ getfacl --all-effective acldir/aclfile 
# file: acldir/aclfile
# owner: saml
# group: saml
user::rw-
user:nginx:rwx          #effective:rw-
group::r-x          #effective:r--
mask::rw-
other::r--

Remarquez le masque, mask::rw-. Pourquoi n'est-ce pas mask::rwxcomme lorsque le répertoire a été créé?

Vérifiez le luvlyfichier journal pour voir quelles autorisations par défaut ont été utilisées pour la création du fichier:

$ less luvly |grep open |tail -1
10006 1373382808.176797 open("acldir/aclfile", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 3 <0.000060>

C'est là que ça devient un peu déroutant. Avec le masque défini rwxlors de la création du répertoire, vous vous attendriez à ce que le comportement soit identique pour la création du fichier, mais cela ne fonctionne pas de cette façon. C'est parce que le noyau appelle la open()fonction avec les autorisations par défaut de 0666.

Résumer

  • Les fichiers ne seront pas autorisés à exécuter (masquage ou efficace). Peu importe la méthode que nous utilisons: ACL, umask ou mask & ACL.
  • Les répertoires peuvent obtenir des autorisations d'exécution, mais cela dépend de la façon dont le champ de masquage est défini.
  • La seule façon de définir les autorisations d'exécution pour un fichier qui se trouve sous les autorisations ACL est de les définir manuellement à l'aide chmod.

Références


@jofel - faites-moi savoir si cela a du sens.
slm

@sIm merci beaucoup pour votre réponse détaillée. Cela me rapproche de mon problème réel: l'autorisation de groupe dans l'appel système chmod affecte le masque du fichier ( chmod("file",0760)-> mask:rw, chmod("file",0770)-> mask:rwx). Je devrais peut-être commencer une nouvelle question à ce sujet ...
jofel

@jofel - oui cela ressemble à une autre question.
slm

@sIm et il a déjà été répondu ici .
jofel

"Lorsqu'un fichier est créé sur un système Linux, les autorisations par défaut 0666 sont appliquées ..." - eh bien ce n'est pas tout à fait exact, car c'est à l'application de création.
ilkkachu

2

pour des raisons de sécurité, le système d'exploitation linux ne permet pas la création automatique d'un fichier avec un bit d'exécution. Il s'agit d'empêcher les cyber-attaquants d'écrire des programmes dans ces fichiers et de les exécuter s'ils ont accès à votre serveur. C'est juste une mesure de sécurité. Vous devrez toujours définir manuellement le bit d'exécution sur les fichiers après les avoir créés avec l'utilitaire chmod

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.