In che modo umask influenza gli ACL?


12

Qualcuno può spiegarmi in che modo umaskinfluisce sulla maschera predefinita dei file appena creati se gli ACL sono attivati? C'è della documentazione a riguardo?

Esempio:

$ 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::---

Mi aspetterei mask:rwx. In realtà dopo aver impostato, umaskad esempio, 027ottengo il comportamento previsto.


Con un umask di 077, otterrai un mask::rw-. Ma questa non è davvero la tua domanda, giusto?
slm

@slm Questa è una parte della mia domanda. Voglio sapere come la maschera dei nuovi file dipende dall'umask. Sono rimasto piuttosto sorpreso dal fatto che con 077 ottengo mask::rw-e non mask::rwxquale fosse la maschera predefinita della directory.
jofel,

OK, sto aggiornando la mia risposta ora con esempi che dovrebbero aiutare a chiarire questo. Dammi un paio di minuti.
slm

Questa domanda è strettamente correlata.
jofel,

Risposte:


10

Ho trovato questo esempio, intitolato: ACL e MASK in Linux . In questo articolo vengono dimostrati i seguenti esempi che ritengo possano aiutare a comprendere come gli ACL e umaskinteragire tra loro.

sfondo

Quando un file viene creato su un sistema Linux, 0666vengono applicate le autorizzazioni predefinite, mentre quando viene creata una directory 0777vengono applicate le autorizzazioni predefinite .

esempio 1 - file

Supponiamo di impostare umask su 077 e di toccare un file. Possiamo usare straceper vedere cosa sta realmente accadendo quando lo facciamo:

$ 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

In questo esempio possiamo vedere che la chiamata di sistema open()viene effettuata con i permessi 0666, tuttavia quando umask 077viene poi applicato dal kernel le seguenti autorizzazioni vengono rimosse ( ---rwxrwx) e restiamo rw-------alias 0600.

esempio - 2 directory

Lo stesso concetto può essere applicato alle directory, tranne per il fatto che invece che le autorizzazioni predefinite siano 0666, sono 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

Questa volta stiamo usando il mkdircomando. Il mkdircomando ha quindi chiamato la chiamata di sistema mkdir(). Nell'esempio sopra possiamo vedere che il mkdircomando ha chiamato la mkdir()chiamata di sistema con le autorizzazioni defaul 0777( rwxrwxrwx). Questa volta con un'ombra delle 022seguenti autorizzazioni vengono rimossi ( ----w--w-), quindi rimaniamo con 0755 ( rwxr-xr-x) quando vengono create le directory.

esempio 3 (Applicazione dell'ACL predefinito)

Ora creiamo una directory e dimostriamo cosa succede quando viene applicato l'ACL predefinito insieme a un file al suo interno.

$ 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

Ora creiamo il file aclfile:

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

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

Ora ottieni le autorizzazioni per il file appena creato:

$ 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--

Si noti la maschera, mask::rw-. Perché non è mask::rwxproprio come quando è stata creata la directory?

Controlla il luvlyfile di registro per vedere quali autorizzazioni predefinite sono state utilizzate per la creazione del file:

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

Qui è un po 'confuso. Con la maschera impostata su rwxquando è stata creata la directory, ti aspetteresti lo stesso comportamento per la creazione del file, ma non funziona in questo modo. È perché il kernel chiama la open()funzione con le autorizzazioni predefinite di 0666.

Riassumere

  • I file non ottengono il permesso di esecuzione (mascheramento o effettivo). Non importa quale metodo utilizziamo: ACL, umask o mask & ACL.
  • Le directory possono ottenere le autorizzazioni di esecuzione, ma dipende da come è impostato il campo di mascheramento.
  • L'unico modo per impostare le autorizzazioni di esecuzione per un file che si trova nelle autorizzazioni ACL è impostarle manualmente utilizzando chmod.

Riferimenti


@jofel - fammi sapere se questo ha senso.
slm

@sIm ti ringrazio molto per la tua risposta dettagliata. Mi avvicina al mio vero problema: l'autorizzazione del gruppo nella schermata di controllo di chmod influenza la maschera del file ( chmod("file",0760)-> mask:rw, chmod("file",0770)-> mask:rwx). Forse dovrei iniziare una nuova domanda su questo ...
jofel,

@jofel - sì, sembra un'altra domanda.
slm

@sIm ed è stato già risposto qui .
jofel,

"Quando un file viene creato su un sistema Linux vengono applicate le autorizzazioni predefinite 0666 ..." - beh, non è esattamente corretto, poiché dipende dall'applicazione di creazione.
ilkkachu,

2

per motivi di sicurezza, il sistema operativo linux non consente la creazione automatica di un file con un bit di esecuzione. Questo per impedire agli autori di attacchi informatici di scrivere programmi in tali file e di eseguirli se ottengono l'accesso al server. È solo una precauzione di sicurezza. Dovrai sempre impostare manualmente il bit di esecuzione sui file dopo averli creati con l'utilità chmod

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.