Informazioni sugli elenchi di controllo di accesso NFSv4.x in Azure NetApp Files

Il protocollo NFSv4.x può fornire il controllo di accesso sotto forma di elenchi di controllo di accesso (ACL), concettualmente simili agli ACL usati in SMB tramite autorizzazioni NTFS di Windows. Un ACL NFSv4.x è costituito da singole voci di Controllo di accesso (ACL), ognuna delle quali fornisce una direttiva di controllo di accesso al server.

Ogni ACL NFSv4.x viene creato con il formato type:flags:principal:permissions.

• Type : tipo di ACL definito. Le scelte valide includono Accesso (A), Rifiuto (D), Controllo (U), Avviso (L). Azure NetApp Files supporta tipi di ACL di accesso, rifiuto e controllo, ma gli ACL di controllo, sebbene possano essere impostati, attualmente non producono log di controllo.
• Flag: aggiunge un contesto aggiuntivo per un ACL. Esistono tre tipi di flag ACE: gruppo, ereditarietà e amministrativo. Per altre informazioni sui flag, vedere Flag ACE NFSv4.x.
• Principal : definisce l'utente o il gruppo a cui viene assegnato l'ACL. Un'entità di sicurezza in un ACL NFSv4.x usa il formato di [email protected]. Per informazioni più dettagliate sulle entità di sicurezza, vedere Entità utente e gruppi NFSv4.x.
• Autorizzazioni – dove viene definito il livello di accesso per il principale. Ogni autorizzazione è contrassegnata da una singola lettera (ad esempio, "r" per lettura, "w" per scrittura e così via). L'accesso completo incorpora ogni lettera di autorizzazione disponibile. Per altre informazioni, vedere Autorizzazioni NFSv4.x.

A:g:[email protected]:rwatTnNcCy è un esempio di ACL valido, che segue il type:flags:principal:permissions formato . L'esempio di ACL concede l'accesso completo al gruppo group1 nel dominio ID contoso.com.

Flag ACE NFSv4.x

Un flag ACE consente di fornire altre informazioni su un ACE in un ACL. Ad esempio, se un gruppo ACE viene aggiunto a un ACL, è necessario usare un flag di gruppo per designare che l'entità di sicurezza è un gruppo e non un utente. Negli ambienti Linux è possibile avere un nome utente e un nome di gruppo identici, quindi il flag garantisce che venga rispettato un ACE, e il server NFS deve conoscere il tipo di entità di sicurezza da definire.

È possibile usare altri flag per controllare gli ACE, ad esempio l'ereditarietà e i flag amministrativi.

Flag di accesso e rifiuto

I flag di accesso (A) e deny (D) vengono usati per controllare i tipi ACE di sicurezza. Un ACE di accesso controlla il livello di autorizzazioni di accesso su un file o una cartella per un'entità di sicurezza. Un ACE di negazione proibisce esplicitamente a un'entità di accedere a un file o a una cartella, anche se è impostato un ACE di accesso che consente a tale entità di accedere all'oggetto. Le ACE di negazione prevalgono sempre sulle ACE di accesso. In generale, evitare di usare gli ACL negati, poiché gli ACL NFSv4.x seguono un modello di negazione predefinito, ovvero se non viene aggiunto un ACL, la negazione è implicita. Gli ACE rifiutati possono creare complicazioni non necessarie nella gestione dell'ACL.

Flag di ereditarietà

I flag di ereditarietà controllano il comportamento degli ACL nei file creati sotto una directory padre con il flag di ereditarietà impostato. Quando viene impostato un flag di ereditarietà, i file e/o le directory ereditano gli ACL dalla cartella padre. I flag di ereditarietà possono essere applicati solo alle directory, quindi quando viene creata una sottodirectory, eredita il flag. I file creati sotto una directory padre con un flag di ereditarietà ereditano gli ACL, ma non i flag di ereditarietà.

Nella tabella seguente vengono descritti i flag di ereditarietà disponibili e i relativi comportamenti.

Esempi di ACL NFSv4.x

Nell'esempio seguente sono presenti tre diversi ACE con flag di ereditarietà distinti:

• eredita solo la directory (di)
• eredita solo il file (fi)
• eredita sia file che directory (fdi)

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:[email protected]:rwaDxtTnNcCy
A:fdi:[email protected]:rwaDxtTnNcCy
A:fi:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 ha una directory che eredita solo l'ACL. In una sottodirectory creata sotto l'elemento padre, l'ACL viene ereditato, ma in un file sotto l'elemento padre, non lo è.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:[email protected]:rwaDxtTnNcCy
A:fd:[email protected]:rwaDxtTnNcCy
A:fi:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file 
                       << ACL missing
A::[email protected]:rwaxtTnNcCy
A::[email protected]:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 ha un file e una directory che ereditano il flag. Di conseguenza, sia i file che le directory sotto una directory con tale voce ACE ereditano l'ACL, ma i file non ereditano il flag.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:[email protected]:rwaDxtTnNcCy
A:fd:[email protected]:rwaDxtTnNcCy
A:fi:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::[email protected]:rwaxtTnNcCy << no flag
A::[email protected]:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User3 ha solo un flag di ereditarietà del file. Di conseguenza, solo i file sotto la directory con tale voce ACE ereditano l'ACL, ma non ereditano il flag perché possono essere applicati solo agli ACE della directory.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:[email protected]:rwaDxtTnNcCy
A:fd:[email protected]:rwaDxtTnNcCy
A:fi:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::[email protected]:rwaxtTnNcCy
A::[email protected]:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

Quando un flag "no-propagate" (n) viene impostato su un ACL, i flag vengono cancellati nelle creazioni delle directory successive al di sotto dell'elemento padre. Nell'esempio seguente, user2 ha il flag n impostato. Di conseguenza, la sottodirectory cancella i flag di eredita per l'entità di sicurezza e gli oggetti creati sotto tale sottodirectory non ereditano l'ACE da user2.

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:[email protected]:rwaDxtTnNcCy
A:fdn:[email protected]:rwaDxtTnNcCy
A:fd:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:[email protected]:rwaDxtTnNcCy
A::[email protected]:rwaDxtTnNcCy << flag cleared
A:fd:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:[email protected]:rwaDxtTnNcCy
<< ACL not inherited
A:fd:[email protected]:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

I flag di ereditarietà sono un modo per gestire più facilmente gli ACL NFSv4.x, evitandoti di dover impostare esplicitamente un ACL ogni volta che è necessario.

Flag amministrativi

I flag amministrativi negli ACL NFSv4.x sono flag speciali usati solo con i tipi ACL Audit e Alarm. Questi flag definiscono tentativi di accesso riusciti (S) o non riusciti (F) per le azioni da eseguire.

Questo controllo ACL è un esempio di questo, in cui user1 viene controllato per i tentativi di accesso non riusciti per qualsiasi livello di autorizzazione: U:F:[email protected]:rwatTnNcCy.

Azure NetApp Files supporta solo l'impostazione dei flag amministrativi per gli ACL di controllo, ma gli ACL non funzionano. Gli ACE di allarme non sono supportati in Azure NetApp Files.

Entità di sicurezza utente e gruppo NFSv4.x

Con gli ACL NFSv4.x, le entità utente e di gruppo definiscono gli oggetti specifici a cui deve essere applicato un ace. Le entità di sicurezza seguono in genere un formato di [email protected]. La parte "name" di un'entità di sicurezza può essere un utente o un gruppo, ma tale utente o gruppo deve essere risolvibile in Azure NetApp Files tramite la connessione al server LDAP quando si specifica il dominio ID NFSv4.x. Se il name@domain non è risolvibile da Azure NetApp Files, l'operazione ACL non riesce con un errore di "argomento non valido".

# nfs4_setfacl -a A::[email protected]:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

È possibile controllare all'interno di Azure NetApp Files se un nome può essere risolto usando l'elenco di ID gruppo LDAP. Passare a Supporto e risoluzione dei problemi poi elenco ID gruppo LDAP.

Accesso a utenti e gruppi locali tramite ACL NFSv4.x

Gli utenti e i gruppi locali possono essere usati anche in un ACL NFSv4.x se nell'ACL è specificato solo l'ID numerico. I nomi utente o gli ID numerici con un ID di dominio specificato hanno esito negativo.

Ad esempio:

# nfs4_setfacl -a A:fdg:3003:rwaxtTnNcCy NFSACL
# nfs4_getfacl NFSACL/
A:fdg:3003:rwaxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rwaDxtTnNcy
A::EVERYONE@:rwaDxtTnNcy

# nfs4_setfacl -a A:fdg:[email protected]:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

# nfs4_setfacl -a A:fdg:users:rwaxtTnNcCy NFSACL
Failed setxattr operation: Invalid argument

Quando un utente locale o un gruppo ACL è impostato, qualsiasi utente o gruppo che corrisponde all'ID numerico nell'ACL riceve l'accesso all'oggetto. Per gli ACL del gruppo locale, un utente passa le appartenenze ai gruppi ad Azure NetApp Files. Se l'ID numerico del gruppo con accesso al file tramite la richiesta dell'utente viene visualizzato nel server NFS di Azure NetApp Files, l'accesso è consentito in base all'ACL.

Le credenziali passate dal client al server possono essere visualizzate tramite un'acquisizione di pacchetti, come illustrato di seguito.

Avvertenze:

• L'uso di utenti e gruppi locali per elenchi di controllo di accesso significa che ogni client che accede ai file o alle cartelle deve avere ID utente e gruppo corrispondenti.
• Quando si usa un ID numerico per un ACL, Azure NetApp Files considera implicitamente attendibile la richiesta in ingresso e che l'utente che richiede l'accesso è colui che dichiara di essere, e in effetti è, membro dei gruppi dichiarati. Un utente o un gruppo numerico può essere spoofato se un attore non valido conosce l'ID numerico e può accedere alla rete usando un client con la possibilità di creare utenti e gruppi in locale.
• Se un utente è membro di più di 16 gruppi, qualsiasi gruppo dopo il sedicesimo gruppo (in ordine alfanumerico) viene negato l'accesso al file o alla cartella, a meno che non venga usato LDAP e supporto per gruppi estesi.
• Le stringhe LDAP e nome e cognome@nome di dominio sono altamente consigliate quando si usano ACL NFSv4.x per una migliore gestibilità e sicurezza. Un repository di utenti e gruppi gestito centralmente è più facile da gestire e più difficile da spoofare, rendendo così meno probabile l'accesso degli utenti indesiderati.

Dominio ID NFSv4.x

Il dominio ID è un componente importante del principale, in cui un dominio ID deve corrispondere sia sul client che all'interno di Azure NetApp Files affinché i nomi di utenti e gruppi (in particolare, root) vengano visualizzati correttamente nelle proprietà di file e cartelle.

Azure NetApp Files usa per impostazione predefinita il dominio ID NFSv4.x con le impostazioni del dominio DNS per il volume. Per impostazione predefinita, i client NFS usano anche il dominio DNS come dominio ID per NFSv4.x. Se il dominio DNS del client è diverso dal dominio DNS di Azure NetApp Files, si verifica una mancata corrispondenza. Quando si elencano le autorizzazioni dei file con comandi come ls, gli utenti o i gruppi vengono visualizzati come "nessuno".

Quando si verifica una discrepanza del dominio tra il client NFS e Azure NetApp Files, controllare i log del client per errori simili.

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name '[email protected]' does not map into domain ‘CONTOSO.COM'

È possibile eseguire l'override del dominio ID del client NFS usando l'impostazione "Dominio" del file /etc/idmapd.conf. Ad esempio: Domain = CONTOSO.COM.

Azure NetApp Files consente anche di modificare il dominio ID NFSv4.1. Per altri dettagli, vedere Procedura: Configurazione del dominio ID NFSv4.1 per Azure NetApp Files.

Autorizzazioni NFSv4.x

Le autorizzazioni NFSv4.x consentono di controllare il livello di accesso di un utente o un'entità gruppo specifica in un file o in una cartella. Le autorizzazioni in NFSv3 possono definire solo i livelli di lettura/scrittura/esecuzione (rwx), ma NFSv4.x offre una serie di altri controlli di accesso granulari come un miglioramento rispetto ai bit di modalità NFSv3.

Sono disponibili 13 autorizzazioni che possono essere impostate per gli utenti e 14 autorizzazioni che possono essere impostate per i gruppi.

Quando vengono impostate le autorizzazioni di accesso, un utente o un'entità gruppo rispetta i diritti assegnati.

Esempi di autorizzazioni NFSv4.x

Negli esempi seguenti viene illustrato come funzionano autorizzazioni diverse con diversi scenari di configurazione.

Utente con accesso in lettura (solo r)

Con l'accesso in sola lettura, un utente può leggere attributi e dati, ma qualsiasi accesso in scrittura (dati, attributi, proprietario) viene negato.

A::[email protected]:r

sh-4.2$ ls -la
total 12
drwxr-xr-x 3 root root 4096 Jul 12 12:41 .
drwxr-xr-x 3 root root 4096 Jul 12 12:09 ..
-rw-r--r-- 1 root root    0 Jul 12 12:41 file
drwxr-xr-x 2 root root 4096 Jul 12 12:31 subdir
sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ chown user1 file
chown: changing ownership of ‘file’: Operation not permitted
sh-4.2$ nfs4_setfacl -e /mnt/acl-dir/inherit-dir
Failed setxattr operation: Permission denied
sh-4.2$ rm file
rm: remove write-protected regular empty file ‘file’? y
rm: can't remove ‘file’: Permission denied
sh-4.2$ cat file
Test text

Utente con accesso in lettura (r) e attributi di scrittura (T)

In questo esempio è possibile modificare le autorizzazioni per il file a causa dell'autorizzazione di scrittura (T), ma non è possibile creare file perché è consentito solo l'accesso in lettura. Questa configurazione illustra il tipo di controlli granulari che possono essere forniti dagli ACL NFSv4.x.

A::[email protected]:rT

sh-4.2$ touch user1-file
touch: can't touch ‘user1-file’: Permission denied
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:23 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
-rw-r--r--  1 root     root      10 Jul 12 16:22 file
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rw-r--r--  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ chmod 777 user1-file
sh-4.2$ ls -la
total 60
drwxr-xr-x  3 root     root    4096 Jul 12 16:41 .
drwxr-xr-x 19 root     root   49152 Jul 11 09:56 ..
drwxr-xr-x  3 root     root    4096 Jul 12 12:41 inherit-dir
-rwxrwxrwx  1 user1    group1     0 Jul 12 16:23 user1-file
sh-4.2$ rm user1-file
rm: can't remove ‘user1-file’: Permission denied

Conversione di bit di modalità in autorizzazioni ACL NFSv4.x

Quando viene eseguito un comando chmod su un oggetto a cui sono assegnati ACL NFSv4.x, una serie di ACL di sistema viene aggiornata con le nuove autorizzazioni. Ad esempio, se le autorizzazioni sono impostate su 755, i file ACL di sistema vengono aggiornati. La seguente tabella illustra a quali autorizzazioni ACL di NFSv4 corrisponde ciascun valore numerico dei bit di modalità.

Vedere Autorizzazioni NFSv4.x per una tabella che delinea tutte le autorizzazioni.

Funzionamento degli ACL NFSv4.x con Azure NetApp Files

Azure NetApp Files supporta in modo nativo gli ACL NFSv4.x quando un volume dispone di NFSv4.1 abilitato per l'accesso. Non c'è nulla da abilitare nel volume per il supporto ACL, ma per il funzionamento ottimale degli ACL NFSv4.1, è necessario un server LDAP con utenti e gruppi UNIX per garantire che Azure NetApp Files sia in grado di risolvere le entità impostate negli ACL in modo sicuro. Gli utenti locali possono essere usati con ACL NFSv4.x, ma non forniscono lo stesso livello di sicurezza degli ACL usati con un server LDAP.

Esistono considerazioni da tenere presenti con la funzionalità ACL in Azure NetApp Files.

Ereditarietà ACL

In Azure NetApp Files, le flag di ereditarietà ACL possono essere usate per semplificare la gestione delle ACL con NFSv4.x. Quando viene impostato un flag di ereditarietà, gli ACL in una directory padre possono propagarsi nelle sottodirectory e nei file senza ulteriori interazioni. Azure NetApp Files implementa i comportamenti di eredità standard delle ACL come da RFC-7530.

ACE di rifiuto

Gli ACE di rifiuto in Azure NetApp Files vengono usati per limitare in modo esplicito l'accesso a un file o a una cartella a un utente o a un gruppo. È possibile definire un sottoinsieme di autorizzazioni per fornire controlli granulari sugli ACE di rifiuto. Queste funzionino nei metodi standard indicati in RFC-7530.

Conservazione ACL

Quando un chmod viene eseguito in un file o in una cartella in Azure NetApp Files, tutti gli ACL esistenti vengono mantenuti nell'ACL diverso dagli ACL di sistema (OWNER@, GROUP@, EVERYONE@). Le autorizzazioni ACE vengono modificate in base ai bit di modalità numerica definiti dal comando chmod. È possibile modificare solo gli ACEs che sono stati modificati o rimossi manualmente tramite il comando nfs4_setfacl.

Comportamenti ACL NFSv4.x in ambienti a doppio protocollo

Il protocollo duale si riferisce all'uso di SMB e NFS nello stesso volume di Azure NetApp Files. I controlli di accesso a doppio protocollo sono determinati dallo stile di sicurezza usato dal volume, ma il mapping dei nomi utente garantisce che gli utenti di Windows e UNIX che eseguono correttamente il mapping uno all'altro abbiano le stesse autorizzazioni di accesso ai dati.

Quando gli ACL NFSv4.x sono in uso nei volumi di stile di sicurezza UNIX, è possibile osservare i comportamenti seguenti quando si usano volumi a doppio protocollo e si accede ai dati dai client SMB.

• I nomi utente di Windows devono essere mappati correttamente ai nomi utente UNIX per una risoluzione corretta del controllo di accesso.
• Nei volumi con stile di sicurezza UNIX (in cui verranno applicati gli ACL NFSv4.x), se non esiste un utente UNIX valido nel server LDAP a cui un utente Windows possa essere mappato, viene usato un utente UNIX predefinito chiamato pcuser (con uid numerico 65534) per il mapping.
• I file scritti da utenti Windows senza un mapping utente valido a un utente UNIX vengono visualizzati come di proprietà dell'ID numerico 65534, che corrisponde ai nomi utente “nfsnobody” o “nobody” nei client Linux attraverso mount NFS. Questo è diverso dall'ID numerico 99, in genere visualizzato con problemi di dominio ID NFSv4.x. Per verificare l'ID numerico in uso, usare il ls -lan comando .
• I file con proprietari non corretti non forniscono i risultati previsti dai bit in modalità UNIX o dagli ACL NFSv4.x.
• Gli ACL NFSv4.x vengono gestiti dai client NFS. I client SMB non possono né visualizzare né gestire ACL NFSv4.x.

Impatto di Umask con ACL NFSv4.x

Gli ACL NFSv4 forniscono la possibilità di ereditare le ACL. L'ereditarietà ACL significa che i file o le cartelle creati sotto gli oggetti con ACL NFSv4 possono ereditare gli ACL in base alla configurazione del flag di ereditarietà ACL.

Umask viene usato per controllare il livello di autorizzazione in base al quale vengono creati file e cartelle in una directory. Per impostazione predefinita, Azure NetApp Files consente a umask di eseguire l'override degli ACL ereditati, ovvero il comportamento previsto in base a RFC-7530.

Per altre informazioni, vedere umask.

Comportamento di chmod/chown con le ACL di NFSv4.x

In Azure NetApp Files è possibile usare i comandi change ownership (chown) e change mode bit (chmod) per gestire le autorizzazioni di file e directory in NFSv3 e NFSv4.x.

Quando si usano ACL NFSv4.x, i controlli più granulari applicati ai file e alle cartelle riduce la necessità di comandi chmod. Chown ha ancora un posto, perché gli ACL NFSv4.x non assegnano la proprietà.

Quando chmod viene eseguito in Azure NetApp Files su file e cartelle con ACL NFSv4.x applicati, i bit di modalità vengono modificati nell'oggetto. Inoltre, un set di ACE di sistema viene modificato in modo da riflettere tali bit di modalità. Se le ACE di sistema vengono rimosse, i bit della modalità vengono cancellati. Esempi e una descrizione più completa sono disponibili nella sezione sugli ACL di sistema di seguito.

Quando chown viene eseguito in Azure NetApp Files, il proprietario assegnato può essere modificato. La proprietà dei file non è così critica quando si usano gli ACL NFSv4.x come quando si usano i bit di modalità, poiché gli ACL possono controllare le autorizzazioni in modi che i concetti di base di proprietario/gruppo/tutti non potrebbero. Chown in Azure NetApp Files può essere eseguito solo come root (sia direttamente come root che tramite sudo), poiché i controlli di esportazione sono configurati per consentire solo al root di apportare modifiche alla proprietà. Poiché questo controllo è controllato da una regola dei criteri di esportazione predefinita in Azure NetApp Files, le voci ACL NFSv4.x che consentono modifiche alla proprietà non si applicano.

# su user1
# chown user1 testdir
chown: changing ownership of ‘testdir’: Operation not permitted
# sudo chown user1 testdir
# ls -la | grep testdir
-rw-r--r--  1 user1    root     0 Jul 12 16:23 testdir

La regola della politica di esportazione sul volume può essere adattata per cambiare questo comportamento. Nel menu Criteri di esportazione per il volume, modificare la Modalità Chown in "senza restrizioni".

Una volta modificata, la proprietà può essere modificata dagli utenti diversi da root se hanno diritti di accesso appropriati. Ciò richiede l'autorizzazione ACL "Diventa proprietario" NFSv4.x (designata dalla lettera "o"). La proprietà può essere modificata anche se l'utente che modifica la proprietà è attualmente proprietaria del file o della cartella.

A::[email protected]:rwatTnNcCy  << no ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
chown: changing ownership of 'newfile3': Permission denied

A::[email protected]:rwatTnNcCoy  << with ownership flag (o)

user1@ubuntu:/mnt/testdir$ chown user1 newfile3
user1@ubuntu:/mnt/testdir$ ls -la
total 8
drwxrwxrwx 2 user2 root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root  root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1 root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root  root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 user1 4294967294    0 Jul 14 16:31 newfile3

ACE di sistema

In ogni ACL è presente una serie di ACE di sistema: OWNER@, GROUP@ EVERYONE@. Ad esempio:

A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

Questi ACE corrispondono alle autorizzazioni dei bit di modalità classica visualizzate in NFSv3 e sono direttamente associate a tali autorizzazioni. Quando un chmod viene eseguito su un oggetto, questi elenchi di controllo di accesso di sistema cambiano in modo da riflettere tali autorizzazioni.

# nfs4_getfacl user1-file

# file: user1-file
A::[email protected]:rT
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rwaxtTnNcy
A::EVERYONE@:rwaxtTnNcy

# chmod 755 user1-file

# nfs4_getfacl user1-file

# file: user1-file
A::OWNER@:rwaxtTnNcCy
A:g:GROUP@:rxtncy

Se tali ACL di sistema vengono rimossi, la visualizzazione delle autorizzazioni cambia in modo che i bit in modalità normale (rwx) vengano visualizzati come trattini.

# nfs4_setfacl -x A::OWNER@:rwaxtTnNcCy user1-file
# nfs4_setfacl -x A:g:GROUP@:rxtncy user1-file
# nfs4_setfacl -x A::EVERYONE@:rxtncy user1-file
# ls -la | grep user1-file
----------  1 user1 group1     0 Jul 12 16:23 user1-file

La rimozione degli ACL di sistema è un modo per proteggere ulteriormente file e cartelle, in quanto solo le entità utente e gruppo nell'ACL (e radice) sono in grado di accedere all'oggetto. La rimozione degli ACE di sistema può interrompere le applicazioni che si basano sulle visualizzazioni dei bit di modalità per la funzionalità.

Comportamento dell'utente root con ACL NFSv4.x

L'accesso radice con ACL NFSv4.x non può essere limitato, a meno che la radice non venga sottoposta a squash. Lo squashing della radice è una configurazione di una regola dei criteri di esportazione in cui l'utente root viene mappato a un utente anonimo per limitare l'accesso. L'accesso radice può essere configurato dal menu Criteri di esportazione di un volume modificando la regola dei criteri di Accesso radice su disattivata.

Per configurare lo squashing della radice, passare al menu Esporta criteri nel volume e quindi impostare "Accesso radice" su "disattivato" per la regola dei criteri.

Effetto della disabilitazione degli squash radice di accesso della radice all'utente anonimo nfsnobody:65534. L'accesso radice non è quindi in grado di modificare la proprietà.

root@ubuntu:/mnt/testdir# touch newfile3
root@ubuntu:/mnt/testdir# ls -la
total 8
drwxrwxrwx 2 user2  root       4096 Jul 14 16:31 .
drwxrwxrwx 5 root   root       4096 Jul 13 13:46 ..
-rw-r--r-- 1 user1  root          0 Jul 14 15:45 newfile
-rw-r--r-- 1 root   root          0 Jul 14 15:52 newfile2
-rw-r--r-- 1 nobody 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# ls -lan
total 8
drwxrwxrwx 2  1002          0 4096 Jul 14 16:31 .
drwxrwxrwx 5     0          0 4096 Jul 13 13:46 ..
-rw-r--r-- 1  1001          0    0 Jul 14 15:45 newfile
-rw-r--r-- 1     0          0    0 Jul 14 15:52 newfile2
-rw-r--r-- 1 65534 4294967294    0 Jul 14 16:31 newfile3
root@ubuntu:/mnt/testdir# chown root newfile3
chown: changing ownership of 'newfile3': Operation not permitted

In alternativa, negli ambienti a doppio protocollo, gli ACL NTFS possono essere usati per limitare in modo granulare l'accesso radice.

Passaggi successivi

• Configurare i client NFS
• Configurare gli elenchi di controllo di accesso nei volumi NFSv4.1