Le autorizzazioni di bit di modalità coprono solo proprietario, gruppo e tutti gli altri membri della semantica, il che significa che non esistono controlli granulari degli accessi utente per NFSv3 di base. Google Cloud NetApp Volumes non supporta gli ACL POSIX, né gli attributi estesi (come chattr), pertanto gli ACL granulari sono possibili solo nei seguenti scenari con NFSv3:

Entrambi i metodi richiedono una connessione LDAP per la gestione delle identità UNIX e ""LDAP""sono disponibili informazioni valide su utenti e gruppi UNIX (vedere la sezione ) e sono disponibili solo con le istanze NetApp Volumes-Performance. Per utilizzare i volumi di sicurezza NTFS con NFS, è necessario utilizzare il protocollo doppio (SMB e NFSv3) o il protocollo doppio (SMB e NFSv4.1), anche se non vengono effettuate connessioni SMB. Per utilizzare NFSv4,1 ACL con NFSv3 mount, è necessario selezionare Both (NFSv3/NFSv4.1) come tipo di protocollo.

I bit in modalità UNIX standard non forniscono lo stesso livello di granularità delle autorizzazioni fornite dagli ACL NTFS o NFSv4.x. La tabella seguente confronta la granularità delle autorizzazioni tra i bit di modalità NFSv3 e gli ACL NFSv4.1. Per informazioni sugli ACL NFSv4.1, vedere "Nfs4_acl - elenchi di controllo degli accessi NFSv4".

Infine, l'appartenenza al gruppo NFS (sia in NFSv3 che IN NFSV4.x) è limitata a un massimo predefinito di 16 per AUTH_SYS in base ai limiti dei pacchetti RPC. NFS Kerberos fornisce fino a 32 gruppi e gli ACL NFSv4 eliminano la limitazione attraverso ACL granulari di utenti e gruppi (fino a 1024 voci per ACE).

Inoltre, Google Cloud NetApp Volumes offre un supporto esteso del gruppo per estendere i gruppi massimi supportati fino a 32. Questa operazione richiede una connessione LDAP a un server LDAP che contenga identità di gruppo e utenti UNIX valide. Per ulteriori informazioni sulla configurazione, vedere "Creazione e gestione di volumi NFS" nella documentazione di Google.

Con NFSv3, il client e il server non devono mai confermare che l'utente che tenta una lettura o una scrittura con un ID numerico sia un utente valido; è semplicemente implicitamente attendibile. In questo modo, il file system si apre a potenziali violazioni semplicemente eseguendo lo spoofing di qualsiasi ID numerico. Per evitare buchi di sicurezza in questo modo, ci sono alcune opzioni disponibili per Google Cloud NetApp Volumes.

In ultima analisi, la sicurezza NFS è limitata alla versione del protocollo in uso. NFSv3, pur essendo più performante in generale rispetto a NFSv4.1, non fornisce lo stesso livello di sicurezza.

A causa delle funzionalità di sicurezza aggiuntive di NFSv4.1, sono coinvolte alcune dipendenze esterne che non erano necessarie per utilizzare NFSv3 (in modo simile a come SMB richiede dipendenze come Active Directory).

Google Cloud NetApp Volumes offre il supporto per ACL NFSv4.x, che offrono vantaggi distinti rispetto alle normali autorizzazioni in stile POSIX, come ad esempio:

Gli ACL NFSv4 sono diversi dagli ACL a livello di file di Windows (ACL NTFS) ma presentano funzionalità simili. Tuttavia, in ambienti NAS multiprotocollo, se sono presenti ACL NFSv4.1 e si utilizza l'accesso a doppio protocollo (NFS e SMB sugli stessi set di dati), i client che utilizzano SMB2.0 e versioni successive non saranno in grado di visualizzare o gestire gli ACL dalle schede di sicurezza di Windows.

Per riferimento, vengono definiti i seguenti termini:

Quando un client imposta un ACL NFSv4,1 su un file durante un'operazione SETATTR, Google Cloud NetApp Volumes imposta tale ACL sull'oggetto, sostituendo qualsiasi ACL esistente. Se un file non contiene ACL, le autorizzazioni di modalità per il file vengono calcolate dal PROPRIETARIO@, DAL GRUPPO@ e DA EVERYONE@. Se nel file sono presenti SUID/SGID/bit ADESIVI, questi non vengono influenzati.

Quando un client ottiene un ACL NFSv4,1 su un file durante un'operazione GETATTR, Google Cloud NetApp Volumes legge l'ACL NFSv4,1 associato all'oggetto, crea un elenco di ACE e restituisce l'elenco al client. Se il file ha un ACL NT o bit di modalità, un ACL viene costruito dai bit di modalità e restituito al client.

L'accesso viene negato se nell'ACL è presente un ACE DI NEGAZIONE; l'accesso viene concesso se esiste un ACE DI AUTORIZZAZIONE. Tuttavia, l'accesso viene negato anche se nessuna delle ACE è presente nell'ACL.

Un descrittore di sicurezza è costituito da un ACL di sicurezza (SACL) e da un ACL discrezionale (DACL). Quando NFSv4.1 interagisce con CIFS/SMB, il DACL viene mappato uno a uno con NFSv4 e CIFS. Il DACL è costituito dalle ACE DI AUTORIZZAZIONE e NEGAZIONE.

Se di base chmod Viene eseguito su un file o una cartella con gli ACL NFSv4.1 impostati, gli ACL degli utenti e dei gruppi esistenti vengono mantenuti, ma gli ACL PREDEFINITI DI PROPRIETARIO@, GRUPPO@, EVERYONE@ vengono modificati.

Un client che utilizza ACL NFSv4.1 può impostare e visualizzare ACL per file e directory nel sistema. Quando viene creato un nuovo file o sottodirectory in una directory che dispone di un ACL, tale oggetto eredita tutte le ACE nell'ACL che sono state contrassegnate con il appropriato "flag di ereditarietà".

Se un file o una directory dispone di un ACL NFSv4.1, tale ACL viene utilizzato per controllare l'accesso indipendentemente dal protocollo utilizzato per accedere al file o alla directory.

File e directory ereditano ACE da ACL NFSv4 nelle directory principali (possibilmente con modifiche appropriate), purché gli ACE siano stati contrassegnati con i flag di ereditarietà corretti.

Quando viene creato un file o una directory come risultato di una richiesta NFSv4, l'ACL del file o della directory risultante dipende dal fatto che la richiesta di creazione del file includa un ACL o solo permessi di accesso ai file UNIX standard. L'ACL dipende anche dalla presenza o meno di un ACL nella directory principale.

Le autorizzazioni ACL NFSv4.1 utilizzano una serie di valori di lettere maiuscole e minuscole (ad esempio rxtncy) per controllare l'accesso. Per ulteriori informazioni sui valori delle lettere, vedere "PROCEDURA: Utilizzare l'ACL NFSv4".

"Gli ACL NFSv4 offrono l'ereditarietà degli ACL". L'ereditarietà degli ACL indica che i file o le cartelle creati sotto gli oggetti con gli ACL NFSv4.1 impostati possono ereditare gli ACL in base alla configurazione di "Flag di ereditarietà ACL".

"Umask" viene utilizzato per controllare il livello di autorizzazione in base al quale i file e le cartelle vengono creati in una directory senza l'interazione dell'amministratore. Per impostazione predefinita, Google Cloud NetApp Volumes consente a umask di ignorare gli ACL ereditati, comportamento previsto come indicato in "RFC 5661".

Gli ACL NFSv4.1 hanno una formattazione specifica. Il seguente esempio è un insieme ACE su un file:

L'esempio precedente segue le linee guida del formato ACL di:

Un tipo di A significa "consenti". In questo caso, i flag Inherit non vengono impostati, in quanto l'entità non è un gruppo e non include l'ereditarietà. Inoltre, poiché l'ACE non è una voce DI AUDIT, non è necessario impostare gli indicatori di audit. Per ulteriori informazioni sugli ACL NFSv4.1, vedere "http://linux.die.net/man/5/nfs4_acl".

Se l'ACL NFSv4.1 non è impostato correttamente (o una stringa di nomi non può essere risolta dal client e dal server), l'ACL potrebbe non funzionare come previsto oppure la modifica dell'ACL potrebbe non essere applicata e generare un errore.

Gli errori di esempio includono:

Le autorizzazioni NFSv4.1 possono includere attributi DI NEGAZIONE esplicita per PROPRIETARIO, GRUPPO e CHIUNQUE. Ciò è dovuto al fatto che gli ACL di NFSv4.1 sono di tipo default-deny, il che significa che se un ACL non viene esplicitamente concesso da un ACE, viene negato. Gli attributi DI NEGAZIONE esplicita sovrascrivono le ACE DI ACCESSO, esplicite o meno.

GLI ACE DI NEGAZIONE vengono impostati con un tag di attributo di D.

Nell'esempio riportato di seguito, IL GRUPPO@ può disporre di tutte le autorizzazioni di lettura ed esecuzione, ma non di tutti gli accessi in scrittura.

GLI ACE DI NEGAZIONE devono essere evitati ogni volta che è possibile perché possono essere confusi e complicati; GLI ACL CHE NON sono esplicitamente definiti sono implicitamente negati. Quando si impostano LE ACE DI NEGAZIONE, agli utenti potrebbe essere negato l'accesso quando si prevede di ottenere l'accesso.

Il set precedente di ACE equivale a 755 in bit di modalità, il che significa:

Tuttavia, anche se le autorizzazioni vengono regolate sull'equivalente 775, l'accesso può essere negato a causa del NEGAZIONE esplicita impostata su EVERYONE.

NFSv4.1 sfrutta la logica di mappatura del dominio ID come livello di sicurezza per verificare che un utente che tenta di accedere a un montaggio NFSv4.1 sia effettivamente quello che afferma di essere. In questi casi, il nome utente e il nome del gruppo provenienti dal client NFSv4,1 aggiunge una stringa di nomi e la invia all'istanza di Google Cloud NetApp Volumes. Se la combinazione nome utente/gruppo e stringa ID non corrisponde, l'utente e/o il gruppo vengono schiacciati con l'utente nessuno predefinito specificato nel /etc/idmapd.conf file sul client.

Questa stringa ID è un requisito per il corretto rispetto delle autorizzazioni, in particolare quando vengono utilizzati ACL NFSv4.1 e/o Kerberos. Di conseguenza, le dipendenze del server dei name service, come i server LDAP, sono necessarie per garantire la coerenza tra i client e i volumi Google Cloud NetApp per una risoluzione corretta dell'identità dei nomi di utenti e gruppi.

Google Cloud NetApp Volumes utilizza un valore statico per il nome di dominio dell'ID predefinito di defaultv4iddomain.com. Per impostazione predefinita, i client NFS utilizzano il nome di dominio DNS per le impostazioni del nome di dominio ID, ma è possibile modificare manualmente il nome di dominio ID in /etc/idmapd.conf.

Se LDAP è abilitato in Google Cloud NetApp Volumes, Google Cloud NetApp Volumes automatizza il dominio ID NFS per impostarlo su ciò che è configurato per il dominio di ricerca in DNS e i client non dovranno essere modificati a meno che non utilizzino nomi di ricerca di domini DNS diversi.

Quando Google Cloud NetApp Volumes può risolvere un nome utente o un nome di gruppo nei file locali o LDAP, viene utilizzata la stringa di dominio e gli ID di dominio non corrispondenti squash a nessuno. Se Google Cloud NetApp Volumes non riesce a trovare un nome utente o un nome di gruppo nei file locali o LDAP, viene utilizzato il valore ID numerico e il client NFS risolve il nome correttamente (questo è simile al comportamento NFSv3).

Senza modificare il dominio ID NFSv4,1 del client in modo che corrisponda a ciò che sta utilizzando il volume Google Cloud NetApp Volumes, si osserva il seguente comportamento:

Di seguito sono riportati i risultati dello scenario precedente:

Quando i domini ID client e server corrispondono, viene visualizzato lo stesso elenco di file:

Per ulteriori informazioni su questo problema e su come risolverlo, vedere la sezione "NFSv4.1 e l'utente/gruppo nessuno."

Se intendi utilizzare Kerberos con NFS, devi disporre dei seguenti elementi in Google Cloud NetApp Volumes:

Uno dei problemi più comuni riscontrati con una configurazione NFSv4.1 è quando un file o una cartella viene visualizzata in un elenco utilizzando ls di proprietà di user:group combinazione di nobody:nobody.

Ad esempio:

E l'ID numerico è 99.

In alcuni casi, il file potrebbe mostrare il proprietario corretto, ma nobody come gruppo.

Chi non è nessuno?

Il nobody L'utente in NFSv4.1 è diverso da nfsnobody utente. È possibile visualizzare il modo in cui un client NFS vede ciascun utente eseguendo id comando:

Con NFSv4.1 nobody user (utente) è l'utente predefinito definito da idmapd.conf e può essere definito come qualsiasi utente che si desidera utilizzare.

Perché questo accade?

Poiché la sicurezza tramite il mapping della stringa del nome è un insieme di chiavi delle operazioni NFSv4.1, il comportamento predefinito quando una stringa del nome non corrisponde correttamente è quello di schiacciare l'utente a un utente che normalmente non avrà accesso a file e cartelle di proprietà di utenti e gruppi.

Quando vedi nobody Per l'utente e/o il gruppo negli elenchi di file, ciò significa generalmente che qualcosa in NFSv4.1 è configurato in modo errato. La distinzione tra maiuscole e minuscole può entrare in gioco qui.

Ad esempio, se l'utente1@CVSDEMO.LOfix.L (uid 1234, gid 1234) sta accedendo a un'esportazione, allora Google Cloud NetApp Volumes deve essere in grado di trovare l'utente1@CVSDEMO.LOfix. L (uid 1234, gid 1234). Se l'utente in Google Cloud NetApp Volumes è USER1@CVSDEMOO.LORIX L, non corrisponderà (user1 maiuscolo rispetto a user1 minuscolo). In molti casi, nel file dei messaggi sul client è possibile visualizzare quanto segue:

Sia il client che il server devono accettare che un utente sia effettivamente l'identità di chi dichiara di essere, pertanto è necessario controllare quanto segue per garantire che l'utente che il client vede disponga delle stesse informazioni dell'utente che vede Google Cloud NetApp Volumes.

In quasi tutti i casi, se nobody negli elenchi di utenti e gruppi dai client, il problema riguarda la conversione dell'ID di dominio dei nomi di utenti o gruppi tra Google Cloud NetApp Volumes e il client NFS. Per evitare questo scenario, utilizzare LDAP per risolvere le informazioni di utenti e gruppi tra i client e i volumi di Google Cloud NetApp.

Se si utilizza NFSv4.1, durante le operazioni NFS viene eseguita una mappatura di stringa nome, come descritto in precedenza.

Oltre all'utilizzo /var/log/messages Per trovare un problema con gli ID NFSv4, è possibile utilizzare "nfsidmap -l" Sul client NFS per visualizzare i nomi utente correttamente mappati al dominio NFSv4.

Ad esempio, questo è l'output del comando dopo che un utente che può essere trovato dal client e che Google Cloud NetApp Volumes accede a un mount NFSv4.x:

Quando un utente non mappato correttamente nel dominio ID NFSv4.1 (in questo caso, netapp-user) tenta di accedere allo stesso mount e tocca un file, vengono assegnati nobody:nobody, come previsto.

Il nfsidmap -l l'output mostra l'utente pcuser nel display ma non netapp-user; si tratta dell'utente anonimo nella nostra regola dei criteri di esportazione (65534).