Vysvětlení seznamů řízení přístupu NFSv4.x v Azure NetApp Files

Protokol NFSv4.x může poskytovat řízení přístupu ve formě seznamů řízení přístupu (ACL), které se koncepčně podobali seznamům ACL používaným v protokolu SMB prostřednictvím oprávnění systém Windows NT FS. Seznam ACL NFSv4.x se skládá z jednotlivých položek řízení přístupu (ACEs), z nichž každá poskytuje pravidlo řízení přístupu k serveru.

Každý ACL NFSv4.x konkrétně používá formát type:flags:principal:permissions.

Typ – typ ACL, který se definuje. Mezi platné volby patří Access (A), Odepřít (D), Audit (U), Alarm (L). Azure NetApp Files podporuje typy ACL pro přístup, odepření a auditování, ale seznamy ACL auditu, zatímco je možné je nastavit, v současné době nevytvářejí protokoly auditu.
Příznaky – přidává další kontext pro ACL. Existují tři druhy příznaků ACE: skupina, dědičnost a správa. Další informace o příznacích viz příznaky NFSv4.x ACE.
Principál – definuje uživatele nebo skupinu, které může být přiřazen ACL. Principál v NFSv4.x ACL používá formát name@ID-DOMAIN-STRING.COM. Podrobnější informace o uživatelských a skupinových identitách naleznete v části principály NFSv4.x.
Oprávnění – jak je definována úroveň přístupu pro hlavní entitu. Oprávnění jsou určena jedním písmenem. Například "r" uděluje oprávnění ke čtení, "w" uděluje oprávnění k zápisu. Úplný přístup by zahrnoval každé dostupné písmeno oprávnění. Další informace naleznete v oprávnění NFSv4.x.

A:g:group1@contoso.com:rwatTnNcCy je příkladem platného ACL v formátu type:flags:principal:permissions. Ukázkový příklad ACL uděluje úplný přístup ke skupině group1 v doméně ID contoso.com.

Příznaky ACE NFSv4.x

Příznak ACE pomáhá poskytovat další informace o ACE v ACL. Pokud je například skupina ACE přidána do seznamu ACL, musí být použit příznak skupiny k označení, že hlavní objekt je skupina, nikoli uživatel. V linuxových prostředích je možné mít uživatele a skupinu se stejným názvem, proto příznak zajišťuje dodržení ACE a server NFS musí vědět, jaký typ entity je definován.

Další příznaky lze použít k řízení ACE, jako je dědičnost a administrativní příznaky.

Značky přístupu a zamítnutí

Příznaky přístupu (A) a zamítnutí (D) slouží k řízení typů ACE zabezpečení. Přístupové ACE řídí úroveň přístupových oprávnění k souboru nebo složce pro subjekt. Odepření ACE explicitně zakáže objektu zabezpečení v přístupu k souboru nebo složce, a to i v případě, že je nastaven přístup ACE, který objektu zabezpečení umožní přístup k objektu. ACE pro odepření vždy převáží ACE pro přístup. Obecně se vyhněte používání odepření v záznamech ACE, protože seznamy ACL v NFSv4.x sledují model "výchozího odepření", což znamená, že pokud není přidán žádný záznam ACL, odepření je implicitní. ACE pro zamítnutí mohou způsobit zbytečné komplikace při správě seznamu řízení přístupu (ACL).

Příznaky dědičnosti

Příznaky dědičnosti řídí chování seznamů řízení přístupu pro soubory vytvořené pod nadřazeným adresářem s nastaveným příznakem dědičnosti. Pokud je nastaven příznak dědičnosti, soubory a/nebo adresáře dědí seznamy ACL z nadřazené složky. Příznaky dědičnosti je možné použít pouze u adresářů, takže když je vytvořen podadresář, automaticky přebírá příznak. Soubory vytvořené pod nadřazeným adresářem s příznakem dědičnosti dědí seznamy ACL, ale nikoli samotné příznaky dědičnosti.

Následující tabulka popisuje dostupné příznaky dědičnosti a jejich chování.

Příznak dědičnosti	Chování
d	– Adresáře pod nadřazeným adresářem dědí ACL. - Příznak dědičnosti je také zděděný.
f	– Soubory pod nadřazeným adresářem dědí ACL. – U souborů není nastaven příznak dědičnosti.
já	Pouze dědění; ACL se nevztahuje na aktuální adresář, ale musí být aplikována dědičnost na objekty v podadresáři.
n	- Žádné šíření dědičnosti Po zdědění seznamu ACL se u objektů pod nadřazeným objektem vymažou příznaky pro dědění.

Příklady ACL pro NFSv4.x

V tomto příkladu existují tři různé ACE s odlišnými příznaky dědičnosti:

(di) – pouze pro dědění adresáře
(fi) – soubor pouze zděděný
(fdi) – soubor i adresář dědí

# 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 má pouze seznam ACL zděděný z adresáře. V podadresáři vytvořeném pod nadřazeným objektem je seznam ACL zděděný, ale v souboru pod nadřazeným objektem není.

# 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 má příznak dědičnosti souborů a adresářů. Výsledkem je, že jak soubory, tak adresáře pod adresářem s danou položkou ACE dědí seznam ACL, ale soubory nezdědí příznak.

# 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 má pouze příznak dědění souboru. V důsledku toho dědí pouze soubory pod adresářem s danou položkou ACE seznam ACL, ale nedědí příznak, protože ten lze použít pouze u položek ACE adresáře.

# 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

Pokud je příznak "no-propagate" (n) nastavený v seznamu ACL, příznaky se zruší při následných vytvářeních adresářů pod nadřazeným objektem. V následujícím příkladu má user2 nastavený příznak n. V důsledku toho podadresář vymaže příznaky dědění pro tohoto principála a objekty vytvořené pod tímto podadresářem nedědí ACE z 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

Dědicí příznaky umožňují snadnější správu vašich seznamů NFSv4.x ACL, čímž vás ušetří od nutnosti explicitního nastavení ACL pokaždé, když je potřebujete.

Příznaky správy

Příznaky pro správu u NFSv4.x ACL jsou speciální příznaky, které se používají pouze u typů ACL Audit a Alarm. Tyto flagy definují úspěšné (S) nebo neúspěšné (F) pokusy o přístup k akcím, které se mají provést.

Tento auditní seznam ACL je příkladem toho, kde user1 je sledován kvůli neúspěšným pokusům o přístup na libovolné úrovni oprávnění: U:F:user1@contoso.com:rwatTnNcCy.

Azure NetApp Files podporuje pouze nastavení administrativních příznaků pro auditní záznamy řízení přístupu (ACE). Jsou vyžadovány záznamy o řízení přístupu (Audit ACEs) pro protokoly přístupu k souborům. Alarm ACEs nejsou podporovány ve službě Azure NetApp Files.

Hlavní identity uživatele a skupiny NFSv4.x

S ACL pro NFSv4.x, uživatelské a skupinové principy definují specifické objekty, na které se má ACE vztahovat. Ředitelé obecně sledují formát name@ID-DOMAIN-STRING.COM. Pole "name" principála může být uživatelem nebo skupinou, ale tento uživatel nebo skupina musí být v Azure NetApp Files přeloženi pomocí připojení k serveru LDAP, při určení domény ID NFSv4.x. Pokud služba Azure NetApp Files nedokáže přeložit name@domain, operace ACL selže s chybou "neplatný argument".

# nfs4_setfacl -a A::noexist@CONTOSO.COM:rwaxtTnNcCy inherit-file
Failed setxattr operation: Invalid argument

Ve službě Azure NetApp Files můžete zkontrolovat, jestli se dá název přeložit pomocí seznamu ID skupiny LDAP. Přejděte na Podpora + Řešení potíží a poté ID seznam skupin LDAP.

Přístup k místním uživatelům a skupinám přes seznamy přístupových řízení NFSv4.x

Místní uživatele a skupiny lze také použít v seznamu ACL NFSv4.x, pokud je v seznamu ACL zadáno pouze číselné ID. Uživatelská jména nebo číselná ID se zadaným ID domény nefungují.

Například:

# 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

Pokud je nastaven místní uživatel nebo seznam ACL skupiny, získá přístup k objektu libovolný uživatel nebo skupina odpovídající číselnému ID seznamu ACL. Pro místní skupiny ACL předává uživatel svá členství ve skupinách do služby Azure NetApp Files. Pokud se číselné ID skupiny s přístupem k souboru prostřednictvím požadavku uživatele zobrazí na serveru NFS služby Azure NetApp Files, je přístup povolený podle seznamu ACL.

Přihlašovací údaje předávané z klienta na server se dají zobrazit prostřednictvím zachytávání paketů, jak je vidět níže.

Upozornění:

Použití místních uživatelů a skupin pro seznamy ACL znamená, že každý klient, který přistupuje k souborům nebo složkám, musí mít odpovídající ID uživatelů a skupin.
Při použití číselného ID pro ACL služba Azure NetApp Files implicitně důvěřuje tomu, že příchozí požadavek je platný a že uživatel, který žádá o přístup, je tím, kým tvrdí, že je, a je členem skupin, u kterých tvrdí, že je členem. Číselný kód uživatele nebo skupiny může být falšován, pokud chybný aktér zná číselné ID a může k síti přistupovat pomocí klienta s možností vytvářet uživatele a skupiny místně.
Pokud je uživatel členem více než 16 skupin, bude přístup k souboru nebo složce odepřen jakýkoliv skupina po šestnácté skupině (v alfanumerickém pořadí), pokud se nepoužije podpora protokolu LDAP a rozšířené skupiny.
Při použití seznamů ACL NFSv4.x se důrazně doporučuje protokol LDAP a úplné name@domain názvové řetězce pro lepší možnosti správy a zabezpečení. Centrálně spravované úložiště uživatelů a skupin je snazší udržovat a obtížněji falšovat, takže nežádoucí přístup uživatelů bude méně pravděpodobné.

Doména ID NFSv4.x

Doména ID je důležitou součástí hlavního prvku, kde se doména ID musí shodovat jak na straně klienta, tak v Azure NetApp Files, aby se názvy uživatelů a skupin (zejména uživatele s oprávněními root) správně zobrazovaly u vlastnictví souborů nebo složek.

Azure NetApp Files východiskově nastaví doménu ID NFSv4.x podle nastavení domény DNS pro svazek. Klienti NFS také ve výchozím nastavení používají doménu DNS pro doménu ID NFSv4.x. Pokud se doména DNS klienta liší od domény DNS služby Azure NetApp Files, dojde k neshodě. Při výpisu oprávnění k souborům pomocí příkazů, jako je ls, se uživatelé nebo skupiny zobrazí jako "nikdo".

Pokud dojde k neshodě domény mezi klientem NFS a službou Azure NetApp Files, zkontrolujte, jestli protokoly klienta obsahují chyby podobné:

August 19 13:14:29 nfsidmap[17481]: nss_getpwnam: name 'root@microsoft.com' does not map into domain ‘CONTOSO.COM'

Je možné přepsat doménu ID klienta NFS pomocí nastavení "Domain" v souboru /etc/idmapd.conf. Například: Domain = CONTOSO.COM.

Azure NetApp Files také umožňuje změnit doménu ID NFSv4.1. Další podrobnosti najdete v tématu Postupy: Konfigurace domény ID NFSv4.1 pro Azure NetApp Files.

Oprávnění NFSv4.x

Oprávnění NFSv4.x představují způsob řízení úrovně přístupu konkrétního uživatele nebo instančního objektu skupiny v souboru nebo složce. Oprávnění v NFSv3 umožňují pouze úrovně přístupu pro čtení/zápis a spouštění (rwx), ale NFSv4.x poskytuje podrobné řízení přístupu jako vylepšení oproti bitům režimu NFSv3.

Pro uživatele je možné nastavit 13 oprávnění a 14 oprávnění, která je možné nastavit pro skupiny.

Dopis s povolením	Udělená oprávnění
r	Čtení datových a seznamových souborů a složek
w	Zápis dat / vytváření souborů a složek
a	Připojení dat / vytvoření podadresářů
x	Spouštění souborů /procházení adresářů
d	Odstranění souborů nebo adresářů
D	Odstranění podadresářů (pouze adresáře)
t	Čtení atributů (GETATTR)
T	Zápis atributů (SETATTR/chmod)
n	Čtení pojmenovaných atributů
N	Zápis pojmenovaných atributů
c	Čtení seznamů ACL
C	Zapisovat ACLs
o	Změnit vlastníka (chown)
y	Synchronní vstupně-výstupní operace

Když jsou nastavena přístupová oprávnění, uživatel nebo skupinový uživatel se řídí těmito přiřazenými právy.

Příklady oprávnění NFSv4.x

Následující příklady ukazují, jak různá oprávnění fungují s různými scénáři konfigurace.

Uživatel s přístupem pro čtení (pouze r)

S přístupem jen pro čtení může uživatel číst atributy a data, ale jakýkoli přístup k zápisu (data, atributy, vlastník) je odepřen.

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

Uživatel s atributy přístupu pro čtení (r) a zápis (T)

V tomto příkladu je možné oprávnění k souboru změnit z důvodu oprávnění k zápisu (T), ale nelze vytvořit žádné soubory, protože je povolen pouze přístup pro čtení. Tato konfigurace znázorňuje typ podrobných ovládacích prvků NFSv4.x ACL, které můžou poskytovat.

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

Převod bitů režimu na oprávnění ACL pro NFSv4.x

Při spuštění chmod objektu s přiřazenými seznamy ACL NFSv4.x se aktualizuje řada systémových seznamů ACL s novými oprávněními. Pokud jsou například oprávnění nastavená na 755, aktualizují se systémové soubory seznamu ACL. Následující tabulka ukazuje, jak se každá číselná hodnota v režimovém bitu promítá do oprávnění NFSv4 ACL.

Viz oprávnění NFSv4.x pro tabulku, která popisuje všechna oprávnění.

Numerický režim bitu	Odpovídající přístupová práva NFSv4.x
1 – provést (x)	Spouštění, čtení atributů, čtení seznamů ACL, synchronizace I/O (xtcy)
2 – zápis (w)	Zápis, připojení dat, čtení atributů, atributy zápisu, zápis pojmenovaných atributů, čtení seznamů ACL, synchronizace V/V operací (watTNcy)
3 – zápis/spuštění (wx)	Zápis, apendování dat, provádění, čtení atributů, zápis atributů, zápis pojmenovaných atributů, čtení ACL, vstupně-výstupní operace synchronizace (waxtTNcy)
4 – čtení (r)	Čtení, čtení atributů, čtení pojmenovaných atributů, čtení seznamů ACL, vstupně-výstupní operace synchronizace (rtncy)
5 – čtení/spuštění (rx)	Čtení, vykonání, čtení atributů, čtení pojmenovaných atributů, čtení ACL, synchronizace vstupně-výstupních operací (rxtncy)
6 – čtení/zápis (rw)	Čtení, zápis, připojení dat, čtení atributů, zápis atributů, čtení pojmenovaných atributů, zápis pojmenovaných atributů, čtení ACL, synchronizace V/V (rwatTnNcy)
7 – čtení/zápis/vykonání (rwx)	Úplné řízení / všechna oprávnění

Jak ACL NFSv4.x fungují se službou Azure NetApp Files

Azure NetApp Files nativně podporuje ACL NFSv4.x, pokud je na svazku povolen přístup přes NFSv4.1. Na svazku není třeba nic povolovat pro podporu seznamů ACL, ale k tomu, aby seznamy ACL NFSv4.1 fungovaly co nejlépe, je nezbytný server LDAP s uživateli a skupinami UNIX, aby služba Azure NetApp Files mohla bezpečně vyřešit zadané objekty zabezpečení na těchto seznamech ACL. Místní uživatele je možné používat se seznamy ACL NFSv4.x, ale neposkytují stejnou úroveň zabezpečení jako seznamy ACL používané se serverem LDAP.

Je třeba mít na paměti funkcionalitu ACL ve službě Azure NetApp Files.

Dědičnost ACL

V Azure NetApp Files lze příznaky dědičnosti ACL použít ke zjednodušení správy ACL pro NFSv4.x. Pokud je nastaven příznak dědičnosti, seznamy ACL v nadřazeném adresáři se můžou rozšířit až do podadresářů a souborů bez další interakce. Azure NetApp Files implementuje standardní dědičné chování ACL v souladu s RFC-7530.

Odepřít záznamy řízení přístupu

Odepření ACL v Azure NetApp Files slouží k explicitní omezení přístupu uživatele nebo skupiny k souboru nebo složce. Podmnožinu oprávnění lze definovat tak, aby poskytovala podrobné ovládací prvky při odepření ACE. Tyto operace fungují ve standardních metodách uvedených v DOKUMENTU RFC-7530.

Zachování ACL (Seznamu řízení přístupu)

Když se u souboru nebo složky v Azure NetApp Files provede chmod, zachovají se všechny existující záznamy ACE na seznamu ACL s výjimkou systémových záznamů ACE (OWNER@, GROUP@, EVERYONE@). Tato oprávnění ACE jsou upravena podle definice číselných bitů režimu definovaných příkazem chmod. Je možné změnit pouze ACEs, které byly ručně upraveny nebo odebrány pomocí příkazu nfs4_setfacl.

Chování ACL NFSv4.x v prostředích se dvěma protokoly

Duální protokol odkazuje na použití protokolu SMB i NFS na stejném svazku Azure NetApp Files. Řízení přístupu pomocí dvou protokolů je určeno stylem zabezpečení svazku, který se používá, ale mapování uživatelských jmen zajišťuje, že uživatelé systému Windows a UNIX, kteří se úspěšně navzájem mapují, mají stejná přístupová oprávnění k datům.

Při použití seznamů ACL NFSv4.x na svazcích se stylem zabezpečení systému UNIX lze při použití svazků se dvěma protokoly a přístupu k datům z klientů SMB pozorovat následující chování.

Pro řádné vyřešení řízení přístupu je potřeba, aby uživatelská jména systému Windows byla správně přiřazena k uživatelským jménům systému UNIX.
V svazcích se stylem zabezpečení systému UNIX (kde by byly použity seznamy ACL NFSv4.x), pokud na serveru LDAP neexistuje žádný platný uživatel systému UNIX pro uživatele systému Windows, na který se má namapovat, použije se pro mapování výchozí uživatel systému UNIX s názvem pcuser (s číselnou hodnotou uid 65534).
Soubory vytvořené uživateli systému Windows bez platného mapování uživatelů systému UNIX se zobrazují jako vlastněné číselným ID 65534, které odpovídá uživatelským jménům "nfsnobody" nebo "nikdo" v klientech systému Linux z připojení NFS. To se liší od číselného ID 99, což se obvykle projevuje u problémů s doménou NFSv4.x. K ověření používaného číselného ID použijte ls -lan příkaz.
Soubory s nesprávnými vlastníky neposkytují očekávané výsledky z bitů režimu UNIX nebo seznamů ACL NFSv4.x.
ACL NFSv4.x jsou spravovány z klientů NFS. Klienti SMB nemůžou zobrazit ani spravovat seznamy ACL NFSv4.x.

Vliv umask na ACL v NFSv4.x

Seznamy ACL NFSv4 poskytují možnost dědičnosti ACL. Dědičnost seznamu ACL znamená, že soubory nebo složky vytvořené pod objekty s nastavenými seznamy ACL NFSv4 mohou dědit seznamy ACL na základě konfigurace příznaku dědičnosti seznamu ACL.

Umask slouží k řízení úrovně oprávnění, na které se soubory a složky vytvářejí v adresáři. Azure NetApp Files ve výchozím nastavení umožňuje umask přepsat zděděné ACL, což je očekávané chování podle RFC-7530.

Další informace naleznete v tématu umask.

Chování chmod/chown s ACL NFSv4.x

Ve službě Azure NetApp Files můžete ke správě oprávnění k souborům a adresářům v NFSv3 a NFSv4.x použít příkazy pro změnu vlastnictví (chown) a změnu režimu (chmod).

Pokud používáte seznamy ACL NFSv4.x, čím podrobnější jsou ovládací prvky použité na soubory a složky, tím méně je potřeba používat příkazy chmod. Chown má stále místo, protože seznamy řízení přístupu ACL NFSv4.x nepřiřazují vlastnictví.

Při spuštění chmod v Azure NetApp Files na souborech a složkách s použitými seznamy ACL NFSv4.x se v objektu změní bity režimu. Kromě toho se upraví sada systémových ACL tak, aby odrážela tyto bity režimu. Pokud jsou odebrány systémové ACE, vymažou se bity režimu. Příklady a podrobnější popis najdete v části o systémových ACL níže.

Když se ve službě Azure NetApp Files spustí chown, dá se upravit přiřazený vlastník. Při používání seznamů ACL NFSv4.x není vlastnictví souborů tak důležité, jako když používáte bity režimu, protože seznamy ACL se dají použít k řízení oprávnění způsobem, který by základní koncepty vlastníka,skupiny a všech uživatelů nešlo použít. Chown ve službě Azure NetApp Files lze spustit pouze jako root (buď jako root, nebo pomocí sudo), protože ovládací prvky exportu jsou nakonfigurované tak, aby umožňovaly změny vlastnictví pouze uživatelem root. Vzhledem k tomu, že se to řídí výchozím pravidlem zásad exportu ve službě Azure NetApp Files, položky seznamu ACL NFSv4.x, které umožňují úpravy vlastnictví, se nevztahují.

# 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

Pravidlo zásad exportu na svazku lze změnit s cílem změnit toto chování. V nabídce zásad exportu pro svazek upravte režim Chown na "neomezený".

Po úpravě může vlastnictví změnit jiný uživatel než root, pokud mají příslušná přístupová práva. To vyžaduje oprávnění NFSv4.x ACL "Převzít vlastnictví", které je určené písmenem "o". Vlastnictví lze změnit také v případě, že uživatel, který mění vlastnictví, aktuálně vlastní soubor nebo složku.

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

Systémové ACEs

Na každém seznamu ACL existuje řada systémových ACE: OWNER@, GROUP@, EVERYONE@. Příklad:

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

Tyto ACEs odpovídají oprávněním klasických bitů režimu, které byste viděli v NFSv3, a jsou přímo spojeny s těmito oprávněními. Při spuštění chmod na objektu se tyto systémové seznamy ACL změní tak, aby odrážely tato oprávnění.

# 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

Pokud jsou tyto systémové jednotky ACL odebrány, změní se zobrazení oprávnění tak, aby se bity normálního režimu (rwx) zobrazovaly jako pomlčky.

# 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

Odebrání systémových ACE je způsob, jak dále zabezpečit soubory a složky, protože k objektu mají přístup pouze uživatelské a skupinové subjekty v ACL (a root). Odebrání systémových ACL může narušit aplikace, které pro funkce spoléhají na bitová zobrazení režimu.

Chování uživatele root s ACL NFSv4.x

Přístup root s ACL NFSv4.x nelze omezit, pokud není root redukován. Root squashing je metoda, při které se v pravidle exportní politiky konfiguruje, že root uživatel je mapován na anonymního uživatele pro omezení přístupu. Kořenový přístup je možné nakonfigurovat z Export policy menu svazku tím, že změníte pravidlo kořenového přístupu na vypnuto.

Pokud chcete nakonfigurovat root squashing, přejděte do nabídky Exportní zásady na svazku a změňte "Kořenový přístup" na "Vypnuto" pro pravidlo zásad.

Účinek zakázání kořenového přístupu root squashes anonymního uživatele nfsnobody:65534. Kořenový přístup pak nemůže změnit vlastnictví.

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

Případně v prostředích se dvěma protokoly lze seznamy ACL NTFS použít k podrobnému omezení kořenového přístupu.

Další kroky

Váš názor

Byla tato stránka užitečná?

Last updated on 2025-07-10