facl, setfacl, sdílení adresáře, proč cp vloží původní oprávnění souboru do masky facl? Nemělo by to ' být chování cp -p?

Uživatelé v tomto systému jsou opatrní a mají své umasks nastaveny na velmi soukromou 0077. Uživatelé by však chtěli mít adresáře specifické pro skupinu, kde jsou soubory mohou být kopírovány, aby je bylo možné výslovně sdílet jen mezi ostatními členy skupiny. Může existovat více takových sdílených adresářů, i když každý je specifický pro skupinu.

Nastavení skupinového lepivého bitu v daném adresáři, který se má použít ke sdílení, nestačí. Ačkoli nastavení lepivého bitu způsobí, že vlastnictví skupiny bude správné u souborů umístěných v adresáři, oprávnění u uvedených souborů jsou často nastavena tak, že soubory nelze číst ani upravovat, tj. Ve skutečnosti je nelze sdílet. Jen se objeví v seznamu adresářů. Důvodem je, že někteří uživatelé buď nemyslí, nebo nevědí, jak ručně provést požadovanou úpravu oprávnění skupiny, aby umožnili čtení a zápis. Můžeme jim v tom dát pauzu, protože uživatelé nejsou koneckonců administrátoři. acls lze použít k určení, že konkrétní skupina má přístup k souborům ve sdíleném adresáři, bez ohledu na to, jaká by byla oprávnění skupiny bez ACL. To je perfektní řešení, ale není to úplně funkční.

V následujícím textu je sdílená skupina „customer_gateway“ a příklad uživatele, který se pokouší sdílet soubor, je „svw“. Jak je vidět v přepisu, uživatel svw je členem skupiny customer_gateway. Adresář, ve kterém má ke sdílení dojít, se také nazývá „customer_gateway /“

Následující text používá acls. Nastavil jsem oprávnění skupiny, výchozí oprávnění skupiny, masku a výchozí masku. Funguje dobře pro soubory vytvořené v adresáři nebo pro soubory přesunuté tam pomocí cat (nebo tar), ale kupodivu ne pro soubory, které tam „cp“ upravily:

# rm -r customer_gateway/ # umask 0077 # cat ~/script1 mkdir customer_gateway chown :customer_gateway customer_gateway/ chmod g+rwx customer_gateway/ setfacl -m group:customer_gateway:rwX customer_gateway/ setfacl -m d:group:customer_gateway:rwX customer_gateway/ setfacl -m m::rwX customer_gateway/ setfacl -m d:m::rwX customer_gateway/ getfacl customer_gateway cd customer_gateway touch cga cat << EOF > cgb c g b EOF ls -l # . ~/script1 # file: customer_gateway # owner: root # group: customer_gateway user::rwx group::rwx group:customer_gateway:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:customer_gateway:rwx default:mask::rwx default:other::--- total 4 -rw-rw----+ 1 root root 0 Mar 2 20:43 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb # su - svw /home/svw/bin:/usr/local/bin:/usr/bin:/bin (note umask is 0077) > cd /share/customer_gateway/ > groups svw adm dip video plugdev google-sudoers customer_gateway > cat >> cga e f g > cat > cgc c g c > ls -l total 12 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc > ls ~/dat ta tb tc > cat ~/dat/ta > ta > cp ~/dat/tb tb > ls -l total 20 -rw-rw----+ 1 root root 6 Mar 2 20:44 cga -rw-rw----+ 1 root root 6 Mar 2 20:43 cgb -rw-rw----+ 1 svw svw 6 Mar 2 20:44 cgc -rw-rw----+ 1 svw svw 4 Mar 2 20:45 ta -rw-------+ 1 svw svw 4 Mar 2 20:45 tb > getfacl ta # file: ta # owner: svw # group: svw user::rw- group::rwx #effective:rw- group:customer_gateway:rwx #effective:rw- mask::rw- other::--- > getfacl tb # file: tb # owner: svw # group: svw user::rw- group::rwx #effective:--- group:customer_gateway:rwx #effective:--- mask::--- other::--- > 

To ukazuje, že když je soubor vytvořen v adresáři, obdrží výchozí oprávnění a je možné jej sdílet. Uživatelé tam ale své soubory vždy nevytvářejí, obvykle je tam vytvářejí.

Kopírování je ale totéž, protože pro vytvoření kopie musíme nejprve vytvořit nový soubor. Mluvíme o prostá kopie zde, nikoli kopie pro zachování oprávnění. Je to stejné jako v následujícím formuláři, který btw funguje a zkopíruje soubor, který bude možné sdílet v adresáři bez ohledu na jeho původní oprávnění skupiny:

cat < data.in > shared/data.out 

funguje v pohodě, funguje i potrubí přes tar, ale forma

cp data.in shared/data.out 

selže. cat ed soubor získá výchozí masku a výchozí oprávnění. Soubor cp ed si zachová svá oprávnění v masce acl a oprávnění skupiny, jako by to bylo cp -p (ale nebylo to), a tedy efektivní oprávnění číst jako původní soubor, ne to, na co byly nastaveny ACL.

Jako druhý pokus jsem spustil tento experiment s group sticky bit, chmod g + rwxs, spolu s facl ch úhly a získal přesně stejné výsledky. Ačkoli jsou výpisy adresářů hezčí kvůli zobrazení vlastnictví skupiny pro všechny sdílené soubory. Také jsem to spustil pouze s nastaveným skupinovým lepivým bitem, bez setfacl. Stejný výsledek měl také pro zkopírované soubory (takže tváře vypadají docela zbytečně pro adresář, kde jsou soubory kopírovány, aby byly sdíleny).

Na základě čeho a s jakým odůvodněním linuxové tváře rozlišují mezi různými formami vytváření dat? Proč nutit cp, aby zachovala oprávnění, když mu to nebylo řečeno? Jaký důvod by ospravedlnil zmatek způsobený tímto rozdílem mezi kočkou a potrubím přes práci tar, ale cp nefunguje? Chybí mi kouzelné zaklínadlo, které by tento rozdíl dělalo odpařit?

Je tento souhrn správný: tváře vám umožní překonat vlastnictví ke sdílení souborů, při „vytváření“ souborů způsobí, že oprávnění budou tolerantnější než umask, pokud toto vytvoření není způsobeno příkazem cp a z dobrého důvodu, protože … protože proč?

Komentáře

• Jaký operační systém (linuxové distribuce a verze) a jaký systém souborů používáte? Bylo by v pořádku přimět lidi, aby používali cat, možná pro tento účel prostřednictvím vyhrazeného skriptu?
• Máte v úmyslu, aby kterýkoli uživatel ve skupině mohl upravovat nebo mazat jakýkoli soubor, nebo by měl mít taková oprávnění pouze tvůrce? Jinými slovy pouze oprávnění ke čtení (a možná oprávnění ke spuštění) pro o další uživatelé.
• Debian 10. Protože vytváření souborů funguje, ‚ jsem kopíroval kopie přes tar. ‚ balím to jako příkaz proj_cp v / usr / local / bin. Pokud však uživatel musí použít speciální příkaz pro kopírování, mohl by jednoduše jít se skupinovým lepivým bitem bez tváří a nastavit oprávnění. Chci vědět, jak nastavit ACL tak, aby cat tar a cp fungovaly.‘ Myslím si, že je problém s ACL s cp, protože dělají chování cp -p místo chování cp. ‚ Těším se na slyšení od odborníků na oprávnění.
• Skupinové sdílení je opakující se problém s variacemi, jak podotknete. V tomto případě mají vývojáři softwaru přístup k adresáři testovací verze. Je to jejich štítek. Mohou pracovat v tomto adresáři, tlačit, tahat, instalovat ve virtuálním prostředí atd. Problém nastane, když zkopírují věci z jiné oblasti, ve které pracovali, a jejich umasks nejsou nastaveny se skupinovými oprávněními. Je to pro ně matoucí, protože vytváření souborů a kopírování pomocí tar funguje dobře. Je také legrační, že jim musím dát kopírovací skript, který prostě dělá to, co dělá cp. ‚ acls ‚ jsou kouzelné, říkám LOL
• nejsem žádný expert na oprávnění, ale doufám, že mé otázky a vaše odpovědi mohou pomoci odborníkům poskytnout vám relevantní odpovědi.