Informazioni sui bit in modalità in Azure NetApp Files

Le autorizzazioni di accesso ai file in NFS limitano le operazioni che gli utenti e i gruppi possono eseguire una volta montato un volume NAS. I bit in modalità sono una funzionalità chiave delle autorizzazioni dei file NFS in Azure NetApp Files.

Bit in modalità NFS

Le autorizzazioni in modalità bit in NFS forniscono autorizzazioni di base per file e cartelle, usando una rappresentazione numerica standard dei controlli di accesso. I bit in modalità possono essere usati con NFSv3 o NFSv4.1, ma i bit in modalità sono l'opzione standard per proteggere NFSv3 come definito in RFC-1813. Nella tabella seguente viene illustrato il modo in cui tali valori numerici corrispondono ai controlli di accesso.

I valori numerici vengono applicati a segmenti diversi di un controllo di accesso: proprietario, gruppo e tutti gli altri, il che significa che non sono presenti controlli di accesso utente granulari per NFSv3 di base. L'immagine seguente mostra un esempio di come un controllo di accesso in modalità bit può essere costruito per l'uso con un oggetto NFSv3.

Azure NetApp Files non supporta gli ACL POSIX. Pertanto, gli ACL granulari sono possibili solo con NFSv3 quando si usa un volume di stile di sicurezza NTFS con mapping di nomi UNIX to Windows validi tramite un servizio dei nomi, ad esempio Active Directory LDAP. In alternativa, è possibile usare NFSv4.1 con Azure NetApp Files e gli ACL NFSv4.1.

La tabella seguente confronta la granularità delle autorizzazioni tra i bit in modalità NFSv3 e gli ACL NFSv4.x.

Per altre informazioni, vedere Informazioni sugli elenchi di controllo di accesso NFSv4.x.

Bit permanenti, setuid e setgid

Quando si usano bit in modalità con montaggi NFS, la proprietà di file e cartelle si basa su uid e gid dell'utente che ha creato i file e le cartelle. Inoltre, quando viene eseguito un processo, viene eseguito come utente che l'ha avviata e quindi avrà le autorizzazioni corrispondenti. Con autorizzazioni speciali(ad esempio setuid, setgid, , bit permanente), questo comportamento può essere controllato.

Setuid

Il setuid bit è designato da "s" nella parte di esecuzione del bit proprietario di un'autorizzazione. Il setuid bit consente l'esecuzione di un file eseguibile come proprietario del file anziché come l'utente che tenta di eseguire il file. Ad esempio, l'applicazione /bin/passwd ha il setuid bit abilitato per impostazione predefinita, pertanto l'applicazione viene eseguita come radice quando un utente tenta di modificare la password.

# ls -la /bin/passwd 
-rwsr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd

Se il setuid bit viene rimosso, la funzionalità di modifica della password non funzionerà correttamente.

# ls -la /bin/passwd
-rwxr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password: 
New password: 
Retype new password: 
passwd: Authentication token manipulation error
passwd: password unchanged

Quando il setuid bit viene ripristinato, l'applicazione passwd viene eseguita come proprietario (radice) e funziona correttamente, ma solo per l'utente che esegue il comando passwd.

# chmod u+s /bin/passwd
# ls -la /bin/passwd
-rwsr-xr-x 1 root root 68208 Nov 29  2022 /bin/passwd
# su user2
user2@parisi-ubuntu:/mnt$ passwd user1
passwd: You may not view or modify password information for user1.
user2@parisi-ubuntu:/mnt$ passwd
Changing password for user2.
Current password: 
New password: 
Retype new password: 
passwd: password updated successfully

Setuid non ha alcun effetto sulle directory.

Setgid

Il setgid bit può essere usato sia in file che in directory.

Con le directory, setgid può essere usato come modo per ereditare il gruppo proprietario per file e cartelle creati sotto la directory padre con il set di bit. Come setuid, il bit eseguibile viene modificato in "s" o "S".

Ad esempio:

# chmod g+s testdir
# ls -la | grep testdir
drwxrwSrw-  2 user1 group1     4096 Oct 11 16:34 testdir
# who
root     ttyS0        2023-10-11 16:28
# touch testdir/file
# ls -la testdir
total 8
drwxrwSrw- 2 user1 group1 4096 Oct 11 17:09 .
drwxrwxrwx 5 root  root   4096 Oct 11 16:37 ..
-rw-r--r-- 1 root  group1    0 Oct 11 17:09 file

Per i file, setgid si comporta in modo analogo a setuid: gli eseguibili vengono eseguiti usando le autorizzazioni di gruppo del proprietario del gruppo. Se un utente si trova nel gruppo proprietario, l'utente ha accesso per eseguire il file eseguibile quando è impostato setgid. Se non si trovano nel gruppo, non ottengono l'accesso. Ad esempio, se un amministratore vuole limitare quali utenti possono eseguire il mkdir comando in un client, possono usare setgid.

In genere, /bin/mkdir dispone di 755 autorizzazioni con proprietà radice. Ciò significa che chiunque può essere eseguito mkdir su un client.

# ls -la /bin/mkdir 
-rwxr-xr-x 1 root root 88408 Sep  5  2019 /bin/mkdir

Per modificare il comportamento in modo da limitare gli utenti che possono eseguire il mkdir comando, modificare il gruppo proprietario dell'applicazione mkdir , modificare le autorizzazioni per /bin/mkdir in 750 e quindi aggiungere il bit setgid a mkdir.

# chgrp group1 /bin/mkdir
# chmod g+s /bin/mkdir
# chmod 750 /bin/mkdir
# ls -la /bin/mkdir
-rwxr-s--- 1 root group1 88408 Sep  5  2019 /bin/mkdir

Di conseguenza, l'applicazione viene eseguita con autorizzazioni per group1. Se l'utente non è membro di group1, l'utente non ottiene l'accesso per eseguire mkdir.

User1 è un membro di group1, ma user2 non è:

# id user1
uid=1001(user1) gid=1001(group1) groups=1001(group1)
# id user2
uid=1002(user2) gid=2002(group2) groups=2002(group2)

Dopo questa modifica, user1 può eseguire mkdir, ma user2 non può perché user2 non è in group1.

# su user1
$ mkdir test
$ ls -la | grep test
drwxr-xr-x  2 user1 group1     4096 Oct 11 18:48 test

# su user2
$ mkdir user2-test
bash: /usr/bin/mkdir: Permission denied

Bit appiccicoso

Il bit sticky viene usato solo per le directory e, se usato, controlla quali file possono essere modificati in tale directory indipendentemente dalle relative autorizzazioni di bit in modalità. Quando viene impostato un bit permanente, solo i proprietari di file (e la radice) possono modificare i file, anche se le autorizzazioni dei file vengono visualizzate come "777".

Nell'esempio seguente la directory "sticky" si trova in un volume Azure NetApp Fils e dispone di autorizzazioni aperte ampie, ma il bit permanente è impostato.

# mkdir sticky
# chmod 777 sticky
# chmod o+t sticky
# ls -la | grep sticky
drwxrwxrwt  2 root  root       4096 Oct 11 19:24 sticky

All'interno della cartella sono file di proprietà di utenti diversi. Tutti hanno 777 autorizzazioni.

# ls -la
total 8
drwxrwxrwt 2 root     root   4096 Oct 11 19:29 .
drwxrwxrwx 8 root     root   4096 Oct 11 19:24 ..
-rwxr-xr-x 1 user2    group1    0 Oct 11 19:29 4913
-rwxrwxrwx 1 UNIXuser group1   40 Oct 11 19:28 UNIX-file
-rwxrwxrwx 1 user1    group1   33 Oct 11 19:27 user1-file
-rwxrwxrwx 1 user2    group1   34 Oct 11 19:27 user2-file

Normalmente, chiunque sarebbe in grado di modificare o eliminare questi file. Tuttavia, poiché la cartella padre ha un bit permanente impostato, solo i proprietari di file possono apportare modifiche ai file.

Ad esempio, user1 non può modificare né eliminare user2-file:

# su user1
$ vi user2-file
Only user2 can modify this file.
Hi
~
"user2-file"
"user2-file" E212: Can't open file for writing
$ rm user2-file 
rm: can't remove 'user2-file': Operation not permitted

Al contrario, user2 non può modificare né eliminare user1-file perché non è proprietario del file e il bit sticky è impostato nella directory padre.

# su user2
$ vi user1-file
Only user1 can modify this file.
Hi
~
"user1-file"
"user1-file" E212: Can't open file for writing
$ rm user1-file 
rm: can't remove 'user1-file': Operation not permitted

Radice, tuttavia, può comunque rimuovere i file.

# rm UNIX-file 

Per modificare la capacità della radice di modificare i file, è necessario modificare la radice a un utente diverso tramite una regola dei criteri di esportazione di Azure NetApp Files. Per altre informazioni, vedere root squashing.

Umask

Nelle operazioni NFS le autorizzazioni possono essere controllate tramite bit in modalità, che sfruttano gli attributi numerici per determinare l'accesso a file e cartelle. Questi bit in modalità determinano attributi speciali, di lettura, scrittura, esecuzione e di lettura. Numericamente, le autorizzazioni sono rappresentate come:

• Execute = 1
• Lettura = 2
• Scrittura = 4

Le autorizzazioni totali vengono determinate aggiungendo o sottraendo una combinazione dell'oggetto precedente. Ad esempio:

• 4 + 2 + 1 = 7 (può fare tutto)
• 4 + 2 = 6 (lettura/scrittura)

Per altre informazioni, vedere La Guida per le autorizzazioni UNIX.

Umask è una funzionalità che consente a un amministratore di limitare il livello di autorizzazioni consentite a un client. Per impostazione predefinita, umask per la maggior parte dei client è impostato su 0022. 0022 indica che i file creati da tale client vengono assegnati a umask. L'oggetto umask viene sottratto dalle autorizzazioni di base dell'oggetto. Se un volume dispone di autorizzazioni 0777 e viene montato usando NFS a un client con un valore umask pari a 0022, gli oggetti scritti dal client in tale volume hanno accesso 0755 (0777 - 0022).

# umask
0022
# umask -S
u=rwx,g=rx,o=rx 

Tuttavia, molti sistemi operativi non consentono la creazione di file con autorizzazioni di esecuzione, ma consentono alle cartelle di avere le autorizzazioni corrette. Di conseguenza, i file creati con un umask di 0022 potrebbero finire con autorizzazioni 0644. L'esempio seguente usa RHEL 6.5:

# umask
0022
# cd /cdot
# mkdir umask_dir
# ls -la | grep umask_dir
drwxr-xr-x.  2 root     root         4096 Apr 23 14:39 umask_dir

# touch umask_file
# ls -la | grep umask_file
-rw-r--r--.  1 root     root            0 Apr 23 14:39 umask_file

Passaggi successivi

• Informazioni sui gruppi ausiliari/supplementari con NFS
• Informazioni sugli elenchi di controllo di accesso NFSv4.x