I permessi dei bit di modalità riguardano solo il proprietario, il gruppo e tutti gli altri nella semantica, il che significa che non sono presenti controlli granulari di accesso utente per NFSv3 di base. Google Cloud NetApp Volumes non supporta ACL POSIX né 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 dell'identità UNIX e informazioni valide su utenti e gruppi UNIX (vedere la sezione"LDAP" ) e sono disponibili solo con istanze NetApp Volumes-Performance. Per utilizzare 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 stabilite connessioni SMB. Per utilizzare gli ACL NFSv4.1 con i mount NFSv3, è necessario selezionare Both (NFSv3/NFSv4.1) come tipo di protocollo.

I bit della modalità UNIX standard non forniscono lo stesso livello di granularità nelle autorizzazioni fornito dagli ACL NTFS o NFSv4.x. Nella tabella seguente viene confrontata la granularità delle autorizzazioni tra i bit della modalità NFSv3 e gli ACL NFSv4.1. Per informazioni sugli ACL NFSv4.1, vedere "nfs4_acl - Elenchi di controllo di accesso 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 rimuovono la limitazione tramite ACL granulari per utenti e gruppi (fino a 1024 voci per ACE).

Inoltre, Google Cloud NetApp Volumes fornisce un supporto di gruppo esteso per estendere il numero massimo di gruppi supportati fino a 32. Ciò richiede una connessione LDAP a un server LDAP che contenga identità utente e di gruppo 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 considerato implicitamente attendibile. Ciò espone il file system a potenziali violazioni semplicemente falsificando un ID numerico. Per prevenire falle di sicurezza come questa, sono disponibili alcune opzioni per Google Cloud NetApp Volumes.

In definitiva, la sicurezza NFS è limitata a ciò che offre la versione del protocollo che si sta utilizzando. NFSv3, pur essendo generalmente più performante di NFSv4.1, non garantisce lo stesso livello di sicurezza.

Grazie alle funzionalità di sicurezza aggiuntive di NFSv4.1, sono coinvolte alcune dipendenze esterne che non erano necessarie per utilizzare NFSv3 (similmente a come SMB richiede dipendenze come Active Directory).

Google Cloud NetApp Volumes offre supporto per ACL NFSv4.x, che offrono vantaggi distintivi rispetto alle normali autorizzazioni in stile POSIX, come i seguenti:

Gli ACL NFSv4 sono diversi dagli ACL a livello di file di Windows (ACL NTFS), ma hanno funzionalità simili. Tuttavia, negli 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.

A titolo di 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 non è presente alcun ACL su un file, le autorizzazioni della modalità sul file vengono calcolate in base a OWNER@, GROUP@ e EVERYONE@. Se nel file sono presenti bit SUID/SGID/STICKY, questi non vengono interessati.

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 a partire dai bit di modalità e restituito al client.

L'accesso viene negato se nell'ACL è presente un DENY ACE; l'accesso viene concesso se è presente un ALLOW ACE. Tuttavia, l'accesso viene negato anche se nessuno dei due 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 è composto dagli ACE ALLOW e DENY.

Se una base chmod se eseguito su un file o una cartella con ACL NFSv4.1 impostati, gli ACL utente e gruppo esistenti vengono conservati, ma gli ACL predefiniti OWNER@, GROUP@, EVERYONE@ vengono modificati.

Un client che utilizza ACL NFSv4.1 può impostare e visualizzare ACL per file e directory sul sistema. Quando un nuovo file o una nuova sottodirectory viene creato in una directory che ha un ACL, quell'oggetto eredita tutti gli ACE nell'ACL che sono stati contrassegnati con l'appropriato "flag di eredità" .

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

I file e le directory ereditano gli ACE dagli ACL NFSv4 sulle directory padre (eventualmente con le opportune modifiche), a condizione che gli ACE siano stati contrassegnati con i flag di ereditarietà corretti.

Quando un file o una directory viene creato come risultato di una richiesta NFSv4, l'ACL sul file o sulla directory risultante varia a seconda che la richiesta di creazione del file includa un ACL o solo le autorizzazioni di accesso ai file UNIX standard. L'ACL dipende anche dal fatto che la directory padre disponga di un ACL.

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 di queste lettere, vedere "COME: utilizzare NFSv4 ACL" .

"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.1 impostati possono ereditare gli ACL in base alla configurazione del "Flag di ereditarietà ACL" .

"Umask"viene utilizzato per controllare il livello di autorizzazione con cui file e cartelle vengono creati in una directory senza l'interazione dell'amministratore. Per impostazione predefinita, Google Cloud NetApp Volumes consente a umask di sovrascrivere gli ACL ereditati, che è il comportamento previsto secondo "RFC 5661" .

Gli ACL NFSv4.1 hanno una formattazione specifica. L'esempio seguente è un ACE impostato su un file:

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

Un tipo di A significa "permettere". In questo caso i flag di ereditarietà non sono impostati, perché il principale non è un gruppo e non include l'ereditarietà. Inoltre, poiché ACE non è una voce AUDIT, non è necessario impostare i flag 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 nome non può essere risolta dal client e dal server), l'ACL potrebbe non comportarsi come previsto oppure la modifica dell'ACL potrebbe non essere applicata e generare un errore.

Esempi di errori includono:

Le autorizzazioni NFSv4.1 possono includere attributi DENY espliciti per OWNER, GROUP e EVERYONE. Ciò avviene perché gli ACL NFSv4.1 sono di tipo default-deny, ovvero se un ACL non viene concesso esplicitamente da un ACE, viene negato. Gli attributi DENY espliciti sovrascrivono qualsiasi ACCESS ACE, esplicito o meno.

Gli ACE DENY sono impostati con un tag di attributo di D .

Nell'esempio seguente, a GROUP@ sono concessi tutti i permessi di lettura ed esecuzione, ma gli è negato tutto l'accesso in scrittura.

Gli ACE DENY dovrebbero essere evitati ove possibile perché possono essere fonte di confusione e complicazioni; gli ACL ALLOW che non sono definiti esplicitamente vengono implicitamente negati. Quando vengono impostati gli ACE DENY, agli utenti potrebbe essere negato l'accesso quando si aspettano che venga concesso.

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

Tuttavia, anche se i permessi vengono modificati in base all'equivalente di 775, l'accesso può essere negato a causa dell'impostazione DENY esplicita 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 mount NFSv4.1 sia effettivamente chi dichiara di essere. In questi casi, il nome utente e il nome del gruppo provenienti dal client NFSv4.1 aggiungono una stringa di nome e la inviano all'istanza di Google Cloud NetApp Volumes . Se la combinazione di nome utente/gruppo e stringa ID non corrisponde, l'utente e/o il gruppo viene compresso nell'utente predefinito nobody specificato in /etc/idmapd.conf file sul client.

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

Google Cloud NetApp Volumes utilizza un valore di nome di dominio ID predefinito statico di defaultv4iddomain.com . I client NFS utilizzano per impostazione predefinita 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 la modifica del dominio ID NFS in base a quanto configurato per il dominio di ricerca in DNS e i client non dovranno essere modificati a meno che non utilizzino nomi di ricerca di dominio DNS diversi.

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

Senza modificare il dominio ID NFSv4.1 del client in modo che corrisponda a quello utilizzato dal volume Google Cloud NetApp Volumes , si verifica il seguente comportamento:

Di seguito sono riportati i risultati dello scenario precedente:

Quando i domini ID client e server corrispondono, ecco come appare lo stesso elenco di file:

Per maggiori informazioni su questo problema e su come risolverlo, consultare la sezione "NFSv4.1 e l'utente/gruppo nobody ."

Se si prevede di utilizzare Kerberos con NFS, è necessario disporre di quanto segue con Google Cloud NetApp Volumes:

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

Per esempio:

E l'ID numerico è 99 .

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

Chi è nessuno?

IL nobody l'utente in NFSv4.1 è diverso dall' nfsnobody utente. È possibile visualizzare come un client NFS vede ciascun utente eseguendo il comando id comando:

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

Perché succede questo?

Poiché la sicurezza tramite la mappatura delle stringhe dei nomi è un principio fondamentale delle operazioni NFSv4.1, il comportamento predefinito quando una stringa dei nomi non corrisponde correttamente è quello di comprimere l'utente in uno che normalmente non avrà accesso ai file e alle cartelle di proprietà di utenti e gruppi.

Quando vedi nobody per l'utente e/o il gruppo negli elenchi dei file, questo in genere significa che qualcosa in NFSv4.1 non è configurato correttamente. Qui può entrare in gioco la distinzione tra maiuscole e minuscole.

Ad esempio, se user1@CVSDEMO.LOCAL (uid 1234, gid 1234) accede a un'esportazione, Google Cloud NetApp Volumes deve essere in grado di trovare user1@CVSDEMO.LOCAL (uid 1234, gid 1234). Se l'utente in Google Cloud NetApp Volumes è USER1@CVSDEMO.LOCAL, non ci sarà corrispondenza (USER1 maiuscolo anziché user1 minuscolo). In molti casi, nel file dei messaggi sul client è possibile visualizzare quanto segue:

Sia il client che il server devono concordare sul fatto che un utente sia effettivamente chi dichiara di essere, pertanto è necessario verificare quanto segue per assicurarsi che l'utente visualizzato dal client abbia le stesse informazioni dell'utente visualizzato da Google Cloud NetApp Volumes .

Nella quasi totalità dei casi, se vedi nobody negli elenchi di utenti e gruppi dei client, il problema è la traduzione dell'ID di dominio del nome utente o gruppo tra Google Cloud NetApp Volumes e il client NFS. Per evitare questo scenario, utilizzare LDAP per risolvere le informazioni sugli utenti e sui gruppi tra i client e Google Cloud NetApp Volumes.

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

Oltre all'utilizzo /var/log/messages per trovare un problema con gli ID NFSv4, puoi usare "nfsidmap -l" comando sul client NFS per visualizzare quali nomi utente sono stati correttamente mappati sul dominio NFSv4.

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

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

IL nfsidmap -l l'output mostra all'utente pcuser nel display ma non netapp-user ; questo è l'utente anonimo nella nostra regola di politica di esportazione(65534 ).