J'essaie de comprendre la différence de comportement entre les ACL FreeBSD et les ACL Linux. En particulier, le mécanisme d'héritage pour les ACL par défaut.
J'ai utilisé ce qui suit sur Debian 9.6 et FreeBSD 12:
$ cat test_acl.sh
#!/bin/sh
set -xe
mkdir storage
setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
touch outside
cd storage
touch inside
cd ..
ls -ld outside storage storage/inside
getfacl -d storage
getfacl storage
getfacl outside
getfacl storage/inside
umask
J'obtiens la sortie suivante de Debian 9.6:
$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r-- 1 aaa aaa 0 Dec 28 11:16 outside
drwxr-xr-x+ 2 aaa aaa 4096 Dec 28 11:16 storage
-rw-rw----+ 1 aaa aaa 0 Dec 28 11:16 storage/inside
+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---
+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x
default:user::rwx
default:group::rwx
default:mask::rwx
default:other::---
+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--
+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx #effective:rw-
mask::rw-
other::---
+ umask
0022
Notez que les fichiers outside
et inside
ont des autorisations différentes. En particulier, le outside
fichier a -rw-r--r--
, qui est la valeur par défaut pour cet utilisateur et le inside
fichier a -rw-rw----
, en respectant les ACL par défaut que j'ai attribuées au storage
répertoire.
La sortie du même script sur FreeBSD 12:
$ ./test_acl.sh
+ mkdir storage
+ setfacl -d -m u::rwx,g::rwx,o::-,m::rwx storage
+ touch outside
+ cd storage
+ touch inside
+ cd ..
+ ls -ld outside storage storage/inside
-rw-r--r-- 1 aaa aaa 0 Dec 28 03:16 outside
drwxr-xr-x 2 aaa aaa 512 Dec 28 03:16 storage
-rw-r-----+ 1 aaa aaa 0 Dec 28 03:16 storage/inside
+ getfacl -d storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::rwx
mask::rwx
other::---
+ getfacl storage
# file: storage
# owner: aaa
# group: aaa
user::rwx
group::r-x
other::r-x
+ getfacl outside
# file: outside
# owner: aaa
# group: aaa
user::rw-
group::r--
other::r--
+ getfacl storage/inside
# file: storage/inside
# owner: aaa
# group: aaa
user::rw-
group::rwx # effective: r--
mask::r--
other::---
+ umask
0022
(Notez que Debian getfacl
affichera également les ACL par défaut même si vous n'utilisez pas où contrairement à -d
FreeBSD, mais je ne pense pas que les ACL réelles pour storage
soient différentes.)
Ici, les fichiers outside
et inside
ont également des autorisations différentes, mais le inside
fichier n'a pas l'autorisation d'écriture de groupe que la version Debian fait, probablement parce que le masque dans Debian a conservé le w
tandis que le masque dans FreeBSD a perdu le w
.
Pourquoi FreeBSD a-t-il perdu le w
masque mais Debian l'a conservé?
la source
getfacl storage
montre- t -on sur les deux systèmes?g+s
)?getfacl
informations.storage
,ls
devrait montrer+
, de même je pensegetfacl
sortie soit semblable à ce que vous avez sur le système Debian. Lesetfacl
code de sortie de réussite a- t-il été renvoyé?Réponses:
En bref, je dirais (supposons) qu'ils utilisent umask différemment.
0022 est exactement un autre groupe non défini W. Vous pouvez modifier umask pour supprimer l'interdiction d'écriture et vérifier le résultat.
Citant le manuel de Solaris aka SunOS (et les commentaires également) car cela semble assez lié: "… L'umask (1) ne sera pas appliqué si le répertoire contient des entrées ACL par défaut.…"
la source
umask
, donc cela semble être un comportement sous-défini. L'implémentation ACL de FreeBSD est-elle censée fonctionner de la même manière que SunOS?