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

Článek
11/19/2023

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 (ACL), z nichž každá poskytuje direktivu řízení přístupu k serveru.

Každý seznam ACL NFSv4.x je vytvořen ve formátu type:flags:principal:permissions.

Typ – typ seznamu ACL, který je definován. 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 seznam ACL. Existují tři druhy příznaků ACE: skupina, dědičnost a správa. Další informace o příznakech najdete v tématu příznaky NFSv4.x ACE.
Objekt zabezpečení – definuje uživatele nebo skupinu, která má přiřazený seznam ACL. Objekt zabezpečení na NFSv4.x ACL používá formát name@ID-DOMAIN-STRING.COM. Podrobnější informace o objektech zabezpečení naleznete v tématu NFSv4.x uživatele a objekty zabezpečení skupiny.
Oprávnění – kde je definována úroveň přístupu pro objekt zabezpečení. Každé oprávnění je určeno jedním písmenem (například čtení získá "r", zápis získá "w" atd.). Úplný přístup by zahrnoval každé dostupné písmeno oprávnění. Další informace naleznete v tématu NFSv4.x oprávnění.

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

Příznaky ACE NFSv4.x

Příznak ACE pomáhá poskytovat další informace o ACE v seznamu ACL. Pokud je například skupina ACE přidána do seznamu ACL, musí být příznak skupiny použit k určení objektu zabezpečení je skupina, nikoli uživatel. V linuxových prostředích je možné mít uživatele a název skupiny, které jsou identické, takže příznak zajišťuje, aby byl dodržen ACE, server NFS musí vědět, jaký typ objektu zabezpečení se definuje.

Další příznaky lze použít k řízení řízení ACL, jako je dědičnost a příznaky správy.

Příznaky přístupu a zamítnutí

Příznaky přístupu (A) a zamítnutí (D) slouží k řízení typů ACE zabezpečení. ACE přístupu řídí úroveň přístupových oprávnění k souboru nebo složce pro objekt zabezpečení. 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. Odepřít řízení přístupu k ACL vždy přerušovat přístup. Obecně platí, že nepoužívejte odepřít ACL, protože seznamy ACL NFSv4.x se řídí modelem výchozího zamítnutí, což znamená, že pokud není přidaný seznam ACL, implicitní je odepření. Odepření ACL může způsobit zbytečné komplikace při správě seznamu ACL.

Příznaky dědičnosti

Příznaky dědičnosti řídí chování seznamů ACL u souborů vytvořených 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ář, dědí příznak. Soubory vytvořené pod nadřazeným adresářem s příznakem dědičnosti dědí seznamy ACL, ale ne 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í seznam ACL. - Příznak dědičnosti je také zděděný.
f	– Soubory pod nadřazeným adresářem dědí seznam ACL. – Soubory nenastaví příznak dědičnosti.
Mohu	Pouze dědění; Seznam ACL se nevztahuje na aktuální adresář, ale musí použít dědičnost u objektů pod adresářem.
n	- Žádné šíření dědičnosti Po zdědění seznam ACL se u objektů pod nadřazeným objektem vymažou příznaky dědění.

Příklady seznamů ACL NFSv4.x

V následujícím příkladu existují tři různé ACL s odlišnými příznaky dědičnosti:

pouze dědění adresáře (di)
soubor dědí jenom (fi)
dědění souborů i adresářů (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 má pouze seznam ACL zděděný adresář. 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ědění souboru a adresáře. Výsledkem je, že soubory i 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í seznam ACL pouze soubory pod adresářem s danou položkou ACE, ale nedědí příznak, protože ho lze použít pouze pro ACL 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 vymažou při následných vytváření adresářů pod nadřazeným objektem. V následujícím příkladu user2 n má nastavený příznak. V důsledku toho podadresář vymaže příznaky dědění pro tento objekt zabezpečení 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ědění příznaků představuje způsob, jak snadněji spravovat seznamy ACL NFSv4.x, což vás při každém použití vyžaduje explicitně nastavení seznamu ACL.

Příznaky správy

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

Azure NetApp Files podporuje nastavení příznaků správy pro audit ACL, ale funkce ACL nefungují. Kromě toho nejsou v Azure NetApp Files podporované alarmové ace.

Objekty zabezpečení uživatele a skupiny NFSv4.x

Se seznamy ACL NFSv4.x definují objekty zabezpečení uživatelů a skupin specifické objekty, na které má ACE platit. Objekty zabezpečení obecně sledují formát name@ID-DOMAIN-STRING.COM. Část "name" objektu zabezpečení může být uživatelem nebo skupinou, ale tento uživatel nebo skupina musí být v Azure NetApp Files přeložit pomocí připojení k serveru LDAP při zadávání domény ID NFSv4.x. Pokud služba Azure NetApp Files nedokáže přeložit name@domain, operace seznamu 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 do části Podpora a řešení potíží a pak seznam ID skupiny LDAP.

Přístup místních uživatelů a skupin přes seznamy ACL 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 nezdaří.

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 seznamy ACL místní skupiny předá uživatel členství ve skupině 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 seznam 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 ten, kdo říká, a je členem skupin, které 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í objektu zabezpečení, kde se doména ID musí shodovat s klientem i v azure NetApp Files pro názvy uživatelů a skupin (konkrétně kořenový adresář), aby se správně zobrazovala u vlastnictví souborů nebo složek.

Azure NetApp Files ve výchozím nastavení nastaví doménu ID NFSv4.x na 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 lsjsou uživatelé nebo skupiny, se 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'

Doménu ID klienta SYSTÉMU SOUBORŮ NFS je možné přepsat pomocí nastavení "Doména" 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 oprávnění	Udělená oprávnění
r	Čtení souborů a složek se seznamem dat
w	Zápis dat / vytváření souborů a složek
d	Připojení dat / vytvoření podadresářů
linka	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	Zápis seznamů ACL
o	Napsat vlastníka (chown)
y	Synchronní vstupně-výstupní operace

Když jsou nastavena přístupová oprávnění, uživatel nebo objekt zabezpečení skupiny dodržuje tato přiřazená práva.

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 do oprávnění seznamu ACL 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, na jakou každou číselnou hodnotu v bitu režimu se překládá v oprávněních seznamu ACL NFSv4.

Projděte si oprávnění NFSv4.x pro tabulku s popisem všech oprávnění.

Bitová čísla režimu	Odpovídající oprávnění NFSv4.x
1 – provedení (x)	Spouštění, čtení atributů, čtení seznamů ACL, vstupně-výstupní operace synchronizace (xtcy)
2 – zápis (w)	Zápis, připojení dat, atributy čtení, atributy zápisu, pojmenované atributy zápisu, seznamy ACL pro čtení, vstupně-výstupní operace synchronizace (watTNcy)
3 – zápis/spuštění (wx)	Zápis, připojení dat, spuštění, čtení atributů, atributy zápisu, pojmenované atributy zápisu, čtení seznamů 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í, spouštění, čtení atributů, čtení pojmenovaných atributů, čtení seznamů ACL, vstupně-výstupní operace synchronizace (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í seznamů ACL, vstupně-výstupní operace synchronizace (rwatTnNcy)
7 – čtení/zápis/execute (rwx)	Úplné řízení / všechna oprávnění

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

Azure NetApp Files nativně podporuje seznamy ACL NFSv4.x, pokud má svazek povolený přístup NFSv4.1. Na svazku není nic možné povolit pro podporu seznamu ACL, ale aby seznamy ACL NFSv4.1 fungovaly co nejlépe, je potřeba server LDAP s uživateli a skupinami UNIX, aby služba Azure NetApp Files mohla bezpečně přeložit objekty zabezpečení nastavené na seznamy 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 potřeba vzít v úvahu funkce seznamu ACL ve službě Azure NetApp Files.

Dědičnost seznamu ACL

V Azure NetApp Files lze příznaky dědičnosti seznamu ACL použít ke zjednodušení správy seznamu ACL pomocí seznamů ACL 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í seznamy ACL chování podle dokumentu RFC-7530.

Odepřít aces

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í seznamu ACL

Když se u souboru nebo složky v Azure NetApp Files provede chmod, zachovají se všechny existující ACL na jiném seznamu ACL než systémové ACL (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 ručně upravené nebo odebrané nfs4_setfacl ace.

Chování seznamu 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 se dvěma protokoly určuje, jaký styl zabezpečení svazku používá, ale mapování uživatelského jména zajišťuje, aby uživatelé systému Windows a uživatelé systému UNIX, kteří se úspěšně mapovali na sebe, 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 správné rozlišení řízení přístupu musí uživatelská jména systému Windows správně namapovat na uživatelská jména 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 napsané s uživateli windows bez platného mapování uživatelů systému UNIX se zobrazují jako vlastněné číselným ID 65534, které odpovídá "nfsnobody" nebo "nikdo" uživatelské jméno 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.
Seznamy ACL NFSv4.x se spravují z klientů NFS. Klienti SMB nemůžou zobrazit ani spravovat seznamy ACL NFSv4.x.

Dopad Umask u seznamů ACL NFSv4.x

Seznamy ACL NFSv4 poskytují možnost nabídnout dědičnost seznamu 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é seznamy ACL, což je očekávané chování podle dokumentu RFC-7530.

Další informace naleznete v tématu umask.

Chování Chmod/chown u seznamů 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 bit režimu změn (chmod).

Pokud používáte seznamy ACL NFSv4.x, tím podrobnější ovládací prvky použité u souborů a složek sníží potřebu příkazů chmod. Chown má stále místo, protože seznamy 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 odebrané systémové ACL, 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 se dá spustit jenom jako kořenový adresář (buď jako root, nebo pomocí sudo), protože ovládací prvky exportu jsou nakonfigurované tak, aby umožňovaly změny vlastnictví jenom kořenového adresáře. 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 tak, aby toto chování změnilo. V nabídce zásad exportu svazku 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í "Převzít vlastnictví" NFSv4.x ACL (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 ACL: OWNER@, GROUP@, EVERYONE@. Příklad:

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

Tyto jednotky ACL odpovídají oprávněním klasických bitů režimu, která byste viděli v NFSv3 a jsou přímo přidružená k těmto oprávněním. 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 ACL je způsob, jak dále zabezpečit soubory a složky, protože k objektu mají přístup pouze objekty ACL (a kořenového seznamu ACL). 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 pomocí seznamů ACL NFSv4.x

Kořenový přístup s seznamy ACL NFSv4.x není možné omezit, pokud není kořen zamkřen. Root squashing je místo, kde je nakonfigurované pravidlo zásad exportu, kde je kořen mapován na anonymního uživatele, aby omezil přístup. Kořenový přístup je možné nakonfigurovat z nabídky zásad exportu svazku tak, že změníte pravidlo zásad kořenového přístupu na vypnuto.

Pokud chcete nakonfigurovat root squashing, přejděte na svazek do nabídky Exportovat zásady 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.

Sdílet prostřednictvím