Dotaz: sdílení adresáře pro dva uživatele s plným přístupem

[Míra]

Potřebuji nastavit práva na společný adresář (např. shareAB) tak, aby dva uživatelé (např. uA a uB) do něj měli právo číst a zapisovat a to i vzájemně. tj. jeden něco napíše a druhý to upraví. Zkoušel jsem nastavovat chmod 2770 shareAB, ale ani to nefunguje spolehlivě. Když někdo vytvoří novou složku, tak druhý v ní už nic neupraví...

Odpovědi

[lertimir]

příkaz chmod je jednorázové změnění práv k souboru. změna implicitních práv pro vytvářené soubory a adresáře pro aktuální shell se provádí příkazem umask. viz man umask. zařazením do logovacího profilu uživatelů umask 002 povolí write přístup pro soubory a adresáře pro skupinu ve které jsou a tím pádem vzájemnou editaci.

[Míra]

Jenže já bych potřeboval umask změnit jen pro ten sdílený adresář, což myslím nejde... Ideální by bylo, kdyby šlo nějak nastavit, že vlastník nového souboru je vždy pevně daný a ne ten skutečný...

[lertimir]

Pokud není nutné to mít okamžitě s těmito právy tak by mohl stačit chmod -r pro daný adresář v cronu. Ale je to trochu prasárna. Na druhou stranu nevidím možnost, jak to ošetřit pro všechny aplikace, nezávisle na aktuálním adresáři.

[pavel]

Ideální by bylo, kdyby šlo nějak nastavit, že vlastník nového souboru je vždy pevně daný a ne ten skutečný...

[SDILENA]
path = /home/karel/sdilena
#Prevzit vlastnika z adresare /home/karel/sdilena
inherit owner = yes
#Prevzit prava z adresare /home/karel/sdilena
inherit permissions = yes
#Pristup ma karel a petr
valid users = karel petr

[Filip Jirsák]

Nastavte tomu adresáři setgid bit, soubory a adresáře v něm vytvořené pak nedostanou primární skupinu uživatele, který je vytvořil, ale zdědí skupinu od rodiče. Bohužel to ale nefunguje rekurzivně, takže ten bit musíte nastavit pro každý nově vytvořený adresář. Další možností je použít ACL a defaultní práva, která se dědí – myslím, že se dědí rekurzivně, ale nejsem si tím jist.

[Míra]

Tak ten setgid jsem taky vyzkoušel, ale došel jsem ke stejnýmu konci. Z dalšíma podadresářema to přestane fungovat, jak bych potřeboval. Mrknu se na ten ACL, ale myslel jsem, že tak základní věc jde v Linuxu snadněji...

[VSi]

Bohužel to ale nefunguje rekurzivně, takže ten bit musíte nastavit pro každý nově vytvořený adresář.

U mě to tedy funguje tak, že když mám adresář s SGID bitem, tak nové adresáře v něm vytvořené (zkoušel jsem mkdir, sftp) ho mají taky nastavený. Jinak by to byla funkce k ničemu.

Další možností je použít ACL a defaultní práva, která se dědí – myslím, že se dědí rekurzivně, ale nejsem si tím jist.

Ano, nejlepší je se rovnou podívat na ACL, je to už úplně standardní věc, jen nebývá ve výchozím stavu zapntá. S výchozími právy je to obdobně jako s SGID bitem - nově vytvořenému adresáři se do jeho ACL zkopírují default položky rodiče. Dá se tedy říct, že je to rekurzivní, i když to je zavádějící název pokud někdo zná NFSv4 nebo NT ACL, kde jsou možnosti dědění komplexnější.

[Míra]

Tak jsem to konečně vyřešil pomocí ACL. Jinak to myslím ani nejde. Kdyby bylo možné nastavit umask na adresář, tak s SGID bitem by to bylo možné také...
Díky všem za pomoc.

[FrantaS]

Jsem snad úplně mimo?

Vytvořil bych speciální skupinu a do ní dal oba uživatele. Vlastník by byl jeden z nich. Uživatel může být ve více skupinách. To přece musí fungovat?

[VSi]

Problém spočívá v tom, že nové soubory budou mít práva 644, adresáře 755 (protože default umask je 022). Takže vlastník bude moci zapisovat, ten druhý už ne. Je potřeba, aby nové soubory v daném adresáři měly právo zápisu i pro skupinu. Bez ACL to spolehlivě neuděláte.

[FrantaS]

Ano, pokud by potřebovali pracovat současně bylo by vhodné nastavit práva okamžitě po vytvoření. (Zadání neříká, že vždy pracují současně.) To by vyřešila v konzoli šipka nahoru nebo CTRL+R nebo spustit na pozadí řádek příkazu do smyčky s např. 10 min. sleep. Ovšem pokud by nepracovali současně, lze využít odhlašování a přihlašování. A pokud bych byl hodně velký lenoch a pracoval bych výjimečně současně, spustím z lišty konzoli a hned ji zavřu. Pokud pracuji současně a chci mít velký komfort, pak ACL.

[Ash]

Standardní řešení jsou tu od toho, aby pomáhala skromným lidem s fantazií.... aby nevymýšleli blbosti :)

[VSi]

Popsané způsoby jsou z mého pohledu prostě obcházení problému pomocí nestandardních řešení. Proč se o to starat ručně nebo pomocí cronu, když řešení pomocí ACL znamená v nejhorším: instalace acl balíčku, editace fstab, online remount, setfacl. Za 2 minuty hotovo, do 5 minut to máte i se čtením manuálu. ACL bezpečně podporují běžně používané filesystemy ext3/4, xfs, reiserfs. Ve Windows NT je tohle od roku 1993, proč tady vymýšlet nějaké speciality? V tomto konkrétním případě, pokud je to desktop, nemusí o nic jít. Je ale dobré se naučit dělat věci pořádně, zvlášť pokud to není nic složitého, což je přesně tento případ.

[FrantaS]

Třeba to tak bude potřebovat jen měsíc a třeba to nemá povolené v kernelu.

[Ash]

Obávám se, že i v tom případě platí co uvedl Vlastimil Šetka. I jednoměsíční uživatelé si zaslouží základní komfort, a není potřeba jim bezostyšně dávat najevo, že správce je lama, takže kvůli němu musí dělat několik těžko obhajitelných úkonů, a podstupovat různá omezení. Něco jiného kdyby to chtěl pro sebe a byl líný. To pak ať klidně přidělává práci s ruční úpravou práv dle libosti.

Nemluvě o tom, že takováto polofunkční provizoria se správci vrátí v podobě různých stížností a nutnosti vysvětlování, takže to je vhodné jen pro BOFHs, kteří to automaticky zkušení zkombinují s tím, že telefon přesměrují na údržbáře a místo serveru zapnou kávovar.

[FrantaS]

Dobrá, dobrá, tak už mě nebijte. :)

Já sdílím názor, že pro admina je ACL systémové řešení. Ale v domácnostech se taky vyskytuje Linux na více strojích a já nevěděl, že je správce sítě.