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 di type:flags:principal:permissions.

• Type : tipo di ACL definito. Le scelte valide includono Access (A), Deny (D), Audit (U), Alarm (L). Azure NetApp Files supporta tipi di ACL di accesso, negazione e controllo, ma controlla ACL, pur essendo in grado di essere impostati, attualmente non producono log di controllo.
• Flag: aggiunge un contesto aggiuntivo per un elenco di controllo di accesso. Esistono tre tipi di flag ACE: gruppo, ereditarietà e amministrazione. 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à in un ACL NFSv4.x usa il formato di name@ID-DOMAIN-STRING.COM. Per informazioni più dettagliate sulle entità di sicurezza, vedere NFSv4.x user and group principals (Entità utente e gruppi NFSv4.x).
• Autorizzazioni : dove viene definito il livello di accesso per l'entità. Ogni autorizzazione è designata una singola lettera (ad esempio, read ottiene "r", la scrittura ottiene "w" e così via). L'accesso completo incorpora ogni lettera di autorizzazione disponibile. Per altre informazioni, vedere Autorizzazioni NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy è un esempio di ACL valido, che segue il type:flags:principal:permissions formato . L'elenco di controllo di accesso di esempio 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 elenco di controllo di accesso, è necessario usare un flag di gruppo per designare l'entità è un gruppo e non un utente. Negli ambienti Linux è possibile avere un utente e un nome di gruppo identici, quindi il flag garantisce che venga rispettato un ace, quindi il server NFS deve conoscere il tipo di entità da definire.

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

Flag di accesso e negazione

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 per un file o una cartella per un'entità. Una ace nega esplicitamente impedisce a un'entità di accedere a un file o a una cartella, anche se è impostato un ace di accesso che consenta a tale entità di accedere all'oggetto. Negare sempre gli ACL di accesso eccessivo. 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 ACL negati 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 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 ACL con flag di ereditarietà distinti:

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

# nfs4_getfacl acl-dir

# file: acl-dir/
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdi:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

User1 ha una directory che eredita solo 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:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM: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::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

User2 ha un file e una directory 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:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy << no flag
A::user3@CONTOSO.COM: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 ACL di directory.

# nfs4_getfacl acl-dir/inherit-dir

# file: acl-dir/inherit-dir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fi:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# nfs4_getfacl acl-dir/inherit-file

# file: acl-dir/inherit-file
A::user2@CONTOSO.COM:rwaxtTnNcCy
A::user3@CONTOSO.COM:rwaxtTnNcCy << no flag
A::OWNER@:rwatTnNcCy
A:g:GROUP@:rtncy
A::EVERYONE@:rtncy

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

#  nfs4_getfacl /mnt/acl-dir

# file: /mnt/acl-dir
A:di:user1@CONTOSO.COM:rwaDxtTnNcCy
A:fdn:user2@CONTOSO.COM:rwaDxtTnNcCy
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

#  nfs4_getfacl inherit-dir/

# file: inherit-dir/
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
A::user2@CONTOSO.COM:rwaDxtTnNcCy << flag cleared
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

# mkdir subdir
# nfs4_getfacl subdir

# file: subdir
A:d:user1@CONTOSO.COM:rwaDxtTnNcCy
<< ACL not inherited
A:fd:user3@CONTOSO.COM:rwaDxtTnNcCy
A::OWNER@:rwaDxtTnNcCy
A:g:GROUP@:rxtncy
A::EVERYONE@:rxtncy

Gli eredita flag sono un modo per gestire più facilmente gli ACL NFSv4.x, risparmiando l'impostazione esplicita di un elenco di controllo di accesso ogni volta che ne è necessario uno.

flag Amministrazione istrative

i flag Amministrazione istrative in 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.

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

NFSv4.x entità utente e gruppo

Con gli ACL NFSv4.x, le entità utente e di gruppo definiscono gli oggetti specifici a cui deve essere applicato un ace. Le entità seguono in genere un formato di name@ID-DOMAIN-STRING.COM. La parte "name" di un'entità 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 NFSv4.x ID. 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::noexist@CONTOSO.COM: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 all'elenco Supporto e risoluzione dei problemi e quindi 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:3003@CONTOSO.COM: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 elenco di controllo di accesso, Azure NetApp Files considera implicitamente attendibile la richiesta in ingresso e che l'utente che richiede l'accesso è chi dichiara di essere e è membro dei gruppi di cui dichiara di essere membro. 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.
• Ldap e stringhe di nome name@domain complete 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 dell'entità, in cui un dominio ID deve corrispondere sia sul client che all'interno di Azure NetApp Files per i nomi di utenti e gruppi (in particolare, radice) per essere visualizzati correttamente nelle proprietà di file/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 sono anche il dominio DNS per il dominio ID 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 mancata corrispondenza del dominio tra il client NFS e Azure NetApp Files, controllare la presenza di errori simili ai log del client:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' 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 consentono solo livelli di lettura/scrittura/esecuzione (rwx) di definizione di accesso, ma NFSv4.x offre un'estensione di altri controlli di accesso granulari come miglioramento rispetto ai bit in 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::user1@CONTOSO.COM: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::user1@CONTOSO.COM: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 in modalità in autorizzazioni ACL NFSv4.x

Quando un chmod viene eseguito un oggetto con ACL NFSv4.x assegnato, viene aggiornata una serie di ACL di sistema con nuove autorizzazioni. Ad esempio, se le autorizzazioni sono impostate su 755, i file ACL di sistema vengono aggiornati. La tabella seguente illustra in che modo ogni valore numerico in un bit in modalità viene convertito nelle autorizzazioni ACL NFSv4.

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 i flag di ereditarietà ACL possono essere usati per semplificare la gestione ACL con ACL NFSv4.x ACL. 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 l'ACL standard eredita i comportamenti in base a RFC-7530.

Nega ACL

Negare gli ACL 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 subset di autorizzazioni per fornire controlli granulari sull'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@). Tali autorizzazioni ACE vengono modificate come definito dai bit in modalità numerica definiti dal comando chmod. È possibile modificare solo gli ACL modificati o rimossi manualmente tramite il nfs4_setfacl comando .

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 di stile di sicurezza UNIX (in cui verranno applicati gli ACL NFSv4.x), se nel server LDAP non esiste un utente UNIX valido a cui eseguire il mapping, viene usato un utente UNIX predefinito chiamato pcuser (con uid numerico 65534) per il mapping.
• I file scritti con utenti di Windows senza mapping utente UNIX valido vengono visualizzati come di proprietà dell'ID numerico 65534, che corrisponde ai nomi utente "nfsnobody" o "nessuno" nei client Linux dai montaggi 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 offrono la possibilità di offrire l'ereditarietà 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 chmod/chown con ACL 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 in file e cartelle con ACL NFSv4.x applicati, i bit in modalità vengono modificati nell'oggetto. Inoltre, un set di ACL di sistema viene modificato in modo da riflettere tali bit di modalità. Se gli ACL di sistema vengono rimossi, 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 è fondamentale quando si usano ACL NFSv4.x come quando si usano bit in modalità, poiché gli ACL possono essere usati per controllare le autorizzazioni in modi in cui non è possibile usare i concetti di base di proprietario/gruppo/tutti. Chown in Azure NetApp Files può essere eseguito solo come radice (come radice o tramite sudo), poiché i controlli di esportazione sono configurati per consentire solo alla radice 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 dei criteri di esportazione nel volume può essere modificata per modificare questo comportamento. Nel menu Esporta criteri per il volume modificare la modalità Chown in "unrestricted".

Una volta modificata, la proprietà può essere modificata dagli utenti diversi da root se hanno diritti di accesso appropriati. Ciò richiede l'autorizzazione ACL "Take Ownership" 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::user1@contoso.com:rwatTnNcCy  << no ownership flag (o)

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

A::user1@contoso.com: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

ACL di sistema

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

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

Questi ACL corrispondono alle autorizzazioni dei bit in 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::user1@CONTOSO.COM: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 ACL di sistema può interrompere le applicazioni che si basano sulle visualizzazioni bit della modalità per la funzionalità.

Comportamento dell'utente radice con ACL NFSv4.x

L'accesso radice con ACL NFSv4.x non può essere limitato, a meno che la radice non venga schiacciata. Lo squash radice è la posizione in cui viene configurata una regola dei criteri di esportazione in cui viene eseguito il mapping della radice 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 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 radice all'utente nfsnobody:65534anonimo. 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