Portál AbcLinuxu, 26. dubna 2024 17:26
acl(7), getfacl(1), setfacl(1)
acl(5)
umask (viz man bash: tedy asi byste chtěl do profilu daných uživatelů umístit umask 0002). Ovšem změníte tím práva souborů vytvořených daným uživatelem kdekoliv, což například při jinak rozumném přístupu (0711) na $HOME nemusí být to pravé oříškové.
umask problém neřeší, protože uživatele nedonutíte, aby si ji před prací ve sdíleném adresáři nastavili potřebným způsobem. A nastavovat jim ji na 007 permanentně není zrovna dobrý nápad.
Ahoj, nedávno jsem řešil podobný problém skupinových přístupových práv na různé adresáře komplikovaný ještě tím že uživatelé k souborům chodili přes sambu.
V tomto případě to není komplikace ale zjednodušení… :-)
Ahoj, nedávno jsem řešil podobný problém skupinových přístupových práv na různé adresáře komplikovaný ještě tím že uživatelé k souborům chodili přes sambu. Do acl se mi rovněž nechtělo. Vyřešil jsem to nakonec skriptem spouštěným cronem jednou za 5 minut který v příslušných adresářích nastavil práva tak jak jsem potřeboval.Proč to řešit jednoduše, když to jde i složitě
Na acl opravdu není nic magického nebo složitého, Samba s tím funguje v pohodě, používám k plné spokojenosti už přes 5 let.
~/pokus: drwxrws---+ ripper sharednasledne jsem u ACL nastavil tato prava:
# file: pokus # owner: ripper # group: shared user::rwx group::rwx group:shared:rwx mask::rwx other::--- default:user::rwx default:group::rwx default:group:shared:rwx default:mask::rwx default:other::---Skupinu shared jsem tam pro jistotu pridal vsude.
file: -rw-r--r-- ripper ripperKdyz ho zkopiruju do ~/pokus, tak ma tato prava:
# file: pokus/file # owner: ripper # group: shared user::rw- group::rwx #effective:r-- group:shared:rwx #effective:r-- mask::r-- other::r--Proste se mi nezachovava maska, a tudiz je to zas nepristupny pro skupinu. V cem je chyba?
Uz zase prehanis.
Myslim, ze naprosto presne ukazal nedostatek. Take by me to stvalo. Jak zajistit dedeni prav z nadrazene slozky je tedy otazka.
Tak si to schválně zrekapitulujme. Moje první odpověď na problém zachování práv při přesunu souboru:
Tak to vás asi zklamu, práva přesunutého souboru (není-li přesunut z jiného filesystému) se logicky měnit nebudou. Přesunout (v rámci filesystému) totiž můžete i soubor, jehož práva nemůžete ani zjistit, natož změnit.
Je to agresivní křik typu RTFM? IMHO ne. Pokud se té odpovědi dá něco vytknout, tak jedině to, že jsem se tam z nepozornosti dopustil tvrzení, které není pravdivé (nemohu přesunout soubor, jehož práva nemohu zjistit, zbytek je ale pravda). Druhá odpověď byl odkaz, že na tento dotaz jsem jednou odpovídal, tazatel se dotázal, zda je to tak i u ACL. Na to jsem odpověděl:
Pro ACL samozřejmě platí totéž. Je vám jasný rozdíl mezi položkou adresáře a i-nodem?
Je to agresivní? IMHO ne. Je tam jemný náznak toho, že tazatel možná nechápe některé podstatné principy fungování filesystému, ale opět nic, co by se dalo označit za "agresivní křik typu RTFM". Teprve když následovala naprosto nesmyslná reakce, odpověděl jsem ostřeji, ale rozhodně ne ostřeji než to, na co jsem reagoval. Ona je tak trochu móda stěžovat si na "namyšlené guru", kteří "jen povýšeně vykřikují RTFM", ale doporučuji si nejdřív pořádně přečíst celou diskusi, než začnete takovéto soudy vydávat.
mam za sebou rok unixu ve skole, a neco o pravech vim.
Promiňte, ale pokud se domníváte, že práva souboru mají vliv na to, zda ho lze smazat, je to zcela zásadní a základní neznalost. Vzhledem k tomu vám těžko mohu vysvětlovat, proč není možné, aby se při přesunutí souboru (v rámci filesystému) změnila jeho přístupová práva. Jasně jsem vám napsal, že to z principu nejde, protože přesouvat můžete i soubory, u kterých ta práva měnit nesmíte. Nevím, zda očekáváte, že vám místo tohoto prostého vysvětlení začnu podrobně popisovat, co je to i-node a jak kontrola oprávnění v unixových systémech funguje, ale na rovinu vám řeknu, že to opravdu dělat nebudu. Místo toho vás odkážu na učebnice, kde je tohle jasně popsáno. Možná vám připadám jako nelida, že místo jednoduché odpovědi radši nebudu popisovat několik stránek tím, co si můžete nastudovat jinde. Pokud je to tak, nic se s tím holt nedá dělat. (Toto nechť považují za odpověď i ti, kdo mne nařkli z &qout;RTFM-ismu" Někdy prostě nezbyde, než si ten f***ing manuál přečíst.)
Jako nápovědu si představte následující situaci: v adresáři A mám soubor s právy r-- pro skupinu, dále mám adresář B, kde je SGID bitem nebo jinak zajištěno, že nově vytvořené soubory mají pro skupinu práva rw-. A teď udělám hardlink toho souboru do adresáře B. Jaká mají být podle vás přístupová práva souboru po této operaci?
26.7.2006 15:51
Nemem9aa | skóre: 13
Nemám moc přehled o učebnících na webu, takže se podívejte sem (doufám, že mi tam nezůstaly nějaké podstatné chyby). Podstatné pro to, o čem se tu bavíme, je hlavně pochopení těch obrázků a uvědomění si, že přístupová práva jsou uložena v i-nodu, zatímco při přesouvání souboru v rámci filesystému se přesouvá pouze adresářová položka (nebo spíš smaže stará a vytvoří nová).
Asi to zkusím nějak přehledně sepsat a dát to do zdejší učebnice, problémy s nepochopením toho, jak unixové filesystémy fungují, jsou bohužel poměrně časté.
zajimalo by me, kde jsem napsal, ze prava souboru maji vliv na to, zda ho lze smazat. ze to porad opakujete, i kdyz jsem napsal, ze se nedomnivam, ze to tak je. zrejme jste si to spatne vylozil.
Tak kdo tedy napsal tohle:
zase maska r--, tudiz nikdo jiny nemuze smazat soubor
To by dávalo smysl jedině že byste mluvil o právech adresáře, ale to by bylo hodně divné (adresář s 400 je skoro k ničemu). Byl to nějaký záškodník, který se za vás vydával, nebo jste to napsal vy?
ale nejste schopen jednoduse napsat napr. "1. presouvani souboru vyresit nelze; 2.kopirovani vyresit lze za pouziti acl
Ale přesně tohle jsem vám napsal, dokonce několikrát. Jenže vy jste to opakovaně ignoroval a pořád opakoval, že byste chtěl, aby to bylo jinak a že je chyba Linuxu, že to nejde, protože to každý začátečník očekává. Nedivte se, že po několikátém zopakování už mi došla trpělivost a doporučil jsem vám, abyste si nejdřív nastudoval, jak ten filesystém vlastně funguje, než z neznalosti začnete kritizovat jeho základní vlastnosti.
a mezitim bylo par mlhavych vet o pravech pri presunu souboru, ktere jsem naprosto nepochopil
Tak jste konečně pochopil v čem je problém: napsal jsem vám, že při přesunu souboru se práva změnit principiálně nemohou, a naznačil, proč tomu tak je. Vy jste to nepochopil. Takže problém není v tom, že bych vám neodpověděl, ale ve vašich nedostatečných znalostech. Proto je zcela legitimní vám doporučit, abyste si je doplnil. Což jsem také udělal. Zkuste se nad tím zamyslet, než kolem sebe zase začnete kopat a nadávat na "namyšlené linuxové guru".
Proste se mi nezachovava maska, a tudiz je to zas nepristupny pro skupinu. V cem je chyba?tohle je fakt divne. trochu jsem patral a vypada to spis na feature nez bug. man acl rika:
The access ACL of a file object is initialized when the object is created with any of the creat(), mkdir(), mknod(), mkfifo(), or open() functions. If a default ACL is associated with a directory, the mode parameter to the functions creating file objects and the default ACL of the directory are used to determine the ACL of the new object:takze pri tvorbe noveho souboru (coz je nas pripad - pri kopirovani nebo presouvani z jineho oddilu se vytvari novy soubor) se acl vytvari nejen podle default acl adresare ale take podle nejakeho zahadneho mode parametru. tenhle mode je uplne v moci aplikace, ktera kopirovani provadi. treba klasicke cp jej nastvuje podle prav zdrojoveho souboru a to i v pripade, ze mu vyslovne rekneme, ze nema zachovavat zadne atributy souboru (--no-preserve=all). vysledkem pak je, ze absence -w- u zdrojoveho souboru se promitne do masky ciloveho souboru. a jak to resit? netusim :(
ale take podle nejakeho zahadneho mode parametru
To není žádný záhadný parametr, to je prostě parametr, kterým proces říká systému, jaká práva má mít nově vytvořený soubor. To není samoúčelné, pokud aplikace chce vytvořit soubor s určitými právy, systém ho tak vytvaří (poté, co je ořeže podle umask). Vámi popisovaný případ se ale týká jen těch položek, které odpovídají klasickým přístupovým právům, tam je zachován pro zpětnou kompatibilitu. Pokud se jedná o položku typu ACL_GROUP, nic takového se dít nebude.
man acl):
http://www.suse.de/~agruen/acl/linux-acls/online/
Z toho co jsem z toho pochopil, tak umask se nepouziva, pokud soubor obsahuje defaultni ACL, ale mode se pouziva vzdy. Navic, zda se, ze kazda funkce pro tvoreni apod. souboru pouziva jiny mode, a nelze to nijak ovlivnit.
Dale jsem se docetl:
Today, the most basic tools that are needed to operate a system with EAs and ACLs are available: there is EA and ACL support in the basic file utilities (ls, cp, and mv), there are utilities for manipulating EAs and ACLs from the command line, and there are solutions for backing up and restoring a system that uses those features. Still, there are many applications that are lacking support. Although for many of them this is irrelevant, there are some classes of applications for which this leads to problems. This includes file managers, editors, and file system synchronization tools. File managers usually can copy and move files and allow permissions to be changed. UNIX kernels have no functions for copying files or for moving files across file system boundaries. Therefore, these operations are implemented by reading from the source file and copying the data to the destination file. The kernel has no way of telling which sequences of operations are file copies or moves and which are something else, so it cannot preserve EAs and ACLs automatically. This means that applications must take care of preserving EAs and ACLs themselves as needed.Coz opravdu jsem zjistil, ze touch vytvori soubor s jinymi pravy, nez vytvoreni noveho souboru v nautilusovi. Coz je teda opravdu neprijemny, lehce receno. Osobne se mi zda, ze ani ACL nebude schopne zajistit sdileny adresar pro uzivatele. A pokud nekdo vi jak to udelat, tak mi prosim ukazte funkcni priklad. Zbyva tedy jeste periodicky spousteni skriptu opravujici prava (docela prasarna, ale co delat, kdyz to nejde slusne), nebo nejaka samba, ftp ci nfs (to teda osobne vubec neznam), coz je sice asi jednoduche reseni problemu, a "vyresi" to i presouvani souboru (protoze se bude zrejme vzdy kopirovat), ale zase pouzivani neni jednoduche. ach jo. asi du studovat sambu.
Navic, zda se, ze kazda funkce pro tvoreni apod. souboru pouziva jiny mode, a nelze to nijak ovlivnit.
Přesněji ne každá funkce, ale každý program. Nakonec každý program, ať už ten soubor vytváří jakkoli, ve skutečnosti volá open() (případně creat()), kterému musí předat práva nově vytvářeného souboru. Logika implementace je taková, že v případě nejasnosti raději přiřadí práva menší. Takže když si proces řekne, že ten soubor nemá mít zápis pro skupinu, systém se pokusí mu vyhovět (i když se to uživateli zrovna moc líbit nemusí).
Osobne se mi zda, ze ani ACL nebude schopne zajistit sdileny adresar pro uzivatele.
V tom smyslu, jak to chápete vy, asi ne. Možná by mohlo pomoci něco, co by využívalo famd nebo nějaký podobný mechanismus. Ale konkrétní řešení vám neporadím.
V tom smyslu, jak to chápete vy, asi ne.Priznavam, ze jsem odkojeny windowsovym svetem, takze mozna nektere postupy a zvyklosti nejsou v poradnych operacnich systemech obvykle. Netrvam na tom, aby to fungovalo presne tak jak rikam, ale nejakym lehce ovladatelnym (pro uzivatele) zpusobem by to melo umoznovat sdilet soubory mezi uzivateli. Pokud se to v unixu dela nejakym jinym zpusobem, nez jsem si predstavoval, tak me to take zajima.
ale nejakym lehce ovladatelnym (pro uzivatele) zpusobem by to melo umoznovat sdilet soubory mezi uzivateli
Možná je problém v tom, že si podvědomě představujete Linux jako náhradu za Windows. Ale tak tomu není, Linux je samostatný operační systém, který vznikl nezávisle na Windows, dokonce několik let před vznikem Windows 95, a navíc je založen na principech, které jsou ještě podstatně starší. V Linuxu samozřejmě není problém sdílet soubory mezi uživateli. To, že se to chová trochu jinak, než jste zvyklý, neznamená, že to nejde. Ve Windows také neuděláte (resp. ne tak snadno) spoustu věcí, které jsou v Linuxu naprosto přirozené. Ty systémy jsou prostě odlišné, jsou postaveny na odlišných principech a i když některé prvky těch systémů vypadají opticky podobně, nezřídka byly navrženy s velmi odlišnou motivací.
Možná vám teď pod dojmem jednoho konkrétního problému připadá myšlenka oddělení i-nodu od adresářové položky chybně navržená, protože vám přináší problémy při řešení požadavku, který vám připadá přirozený. Ale až budete třeba hned zítra potřebovat nahradit běžící program nebo používanou dynamickou knihovnu novou verzí, zjistíte, že ta myšlenka není tak nesmyslná a že má některé nezanedbatelné výhody.
V Linuxu samozřejmě není problém sdílet soubory mezi uživateli. To, že se to chová trochu jinak, než jste zvyklý, neznamená, že to nejde.Jakym zpusobem se to tedy dela?
Prostě jsem tazateli (několikrát) sdělil, že
Co je na tom demagogického?
Naopak, kdybych byl konzultantem, choval bych se úplně jinak. Prostě bych navrhl něco, co by pro klienta vypadalo jako to, co on si představoval, a bylo by mi úplně jedno, jestli rozumí tomu, jak operační systém funguje a proč. Ale právě proto, že zde nejsme ve vztahu konzultant-klient, snažím se slovy oblíbeného příměru "místo darování ryby učit ryby chytat." Možná někteří tazatelé nestojí o to, aby byli takto "vychováváni". V tom případě nechť si místo dotazu na veřejném fóru zaplatí tu konzultantskou firmu, která se vykašle na nějaké principy a bude skákat tak, jak oni budou pískat.
Ano presne s vami souhlasim.
Pan Kubecek asi dobre nepochopil o co tu jde, i kdyz ma absolutni prehled v systemu.
Tazatel chce udelat sdileny adresar, kde normalni uzivale sdileji soubory a nenastavuji prava. A jak se zda, tak to v linuxu nejde jednoduse zajistit. Ja osobne si myslim, jestli to nejde, ze je to pekne v hajzlu.Jdu se na to sam kouknout a tazateli napsat strucne, jestli to jde a nebo ne, a nebo co musi udelat.
Se vší úctou, budu si psát, kam budu chtít a co budu chtít. Pokud jste nechtěl odpověď podle pravdy, ale tak, aby se vám líbila, tak k tomu tady opravdu fórum není. Ode mne jste se dozvěděl pravdivou a úplnou (v mezích možností) odpověď na svou otázku. Že se vám nelíbila, to je váš osobní problém, s tím vám nepomohu. S tím prostě musíte počítat.
Teď jsem třeba zrovna před chvílí odpovídal na dotaz, proč určitá věc nejde v C++ přeložit. Napsal jsem, proč to nejde a co by se s tím dalo dělat. Přesně jako u vás. Jenže ten druhý tazatel místo aby kolem sebe začal kopat jako vy a vykřikovat, že to je nesmysl a že je to C++ na houby, se nad odpovědí zamyslel, zařídil se podle ní a všichni jsou spokojeni. Podobných dotazů bylo samozřejmě víc - schválně se zkuste podívat, kolik dotazů jsem tady zodpověděl za dobu, kterou vy jste místo řešení problému strávil kopáním kolem sebe a brečením, jak jsem na vás zlý a ošklivý. Zkuste se nad tím zamyslet, než si budete zase stěžovat, jak "jste se nic nedozvěděl a jen ztrácel čas". Kdybyste se totiž místo toho ztrácení času hádkami pokusil pochopit odpověď, kterou jste už dávno dostal, mohli jsme teď být oba v klidu a pohodě.
26.7.2006 14:55
multi | skóre: 38
| blog: JaNejsemOdsut
msec nejspíš...
27.7.2006 02:03
Josef Kufner | skóre: 70
. Hodně zdaru.
Jen dovysvětlení, pro koncové uživatele je skoro jedno, či to je přes sambu, jen to budou mít v jiném adresáři, pokud to nenastavíš jinak (douf. že se nepletu? :-? )
)
#!/bin/bash
dir=/home/lefti/pokus
own=lefti:users
perm=660
dir_perm=770
cmd="/home/lefti/bin/check_foo"
if [ $# -eq 0 ]; then
while [ true ];do
dnotify -ra "$dir" --times 1 -e $cmd asdf
echo "reloading"
done
elif [ $# -eq 1 ]; then
chown -R "$own" "$dir"
find "$dir" -type d -exec chmod -R "$dir_perm" {} \;
find "$dir" ! -type d -exec chmod -R "660" {} \;
fi
a]to all_squash zajistí, že se kdokoliv při nějake operaci s /mnt/share stane idshareuzivatele:gidshareskupiny . Tím pádem v tom share budou všechny soubory patřit jednomu uživateli a skupině, a kdokoliv je bude moci mazat atd, protože se "přepne" na toho vlastníka:skupinu. Snad se ti to bude hodit.mkdir /path/shareb] nastavit nfs export:echo "/path/share (rw,all_squash,anonuid=idshareuzivatele,anongid=gidshareskupiny)" >> /etc/exportsc] vyexportovat share:exportfs -ad] namountovat share:mount -tnfs localhost:/path/share /mnt/share
Jak to vyresit v linuxovem souborovem systemu zatim nevim. Proste to moc dobre nejde, protoze kazda aplikace si vse zapisuje jak chce (jak ji nastavime). Ale komu se chce neco takoveho nastavovat.
Nabidnu tedy jen reseni pres Sambu. Mam server a na nej se v podniku pristupuji jen windows klienti pres sambu. Sdilene adresare mam v smb.conf takhle:
[support]
comment = support directory
path = /data01/support
writeable = yes
inherit acls = yes
force group = users
create mask = 0770
directory mask = 0770
Tim jsem zabezpecil, ze vsechna prava pro skupinu (jakoukoliv si zvolite, maji rwx, pro vsechny soubory a adresare, ktere tam prijdou pres sambu.
Tak v tuto chvili preskoumani celeho problemu muzu akorad doporucit prikazem umask 002 zmenit masku pro uzivatele. Od chvile zmeny se soubory boudou vytvaret s rw pravy i pro skupinu.
/etc/profile pro vsechny, nebo v ~/.bash_profile pro konkretniho uzivatele.
Musite si pak dat samozrejme bacha na skupinu, aby nekdo jiny nemohl menit nebo mazat.
U starsich souboru, ktere maji jen read prava pro skupinu, se musi zmenit prava manualne.
Nebo udelat script na dany adresar, ktery bude menit prava prubezne ve stanoveny cas pomoci cronu.
force user force group create mask directory mask security mask directory security mask force security mode force directory security mode acl group control inherit acls inherit permissions inherit ownerPri mountovani jsem zkousel obycejne:
mount //ripper/share /share -t cifs -o guestaz po takoveto veci:
mount //ripper/share /share -t cifs -o guest,noperm,file_mode=0664,dir_mode=0775Zadnou kombinaci se mi nepovedlo poradne to rozchodit. Strucne receno, kopirovani pres nautila (file manager v gnome) funguje vzdy bezvadne, i do namountovaneho adresare. Ale napriklad v midnight commanderu uz to nejde. Pri mountovani prvnim zpusobem to hazi hlasky "chmod: operation not permitted", prava souboru jsou dle nastaveni smb.conf bud v poradku nebo v neporadku. Kazdopadne hlasi to porad, takze i kdyz si prava vynutim, tak se neda kopirovat vice souboru. Zrejme to je proto, ze po zkopirovani chce zmenit chmodem prava, ale uz neni vlastnikem souboru (samba ho zmenila na nobody). To by slo vyresit mountovanim s uzivatelskym jmenem a heslem pro kazdeho uzivatele, ale to by zase slozka nebyla pristupna, aniz by se uzivatel lokalne neprihlasil, coz mi nevyhovuje. Pri mountovani druhym zpusobem uz errory nehazi, ale prava nove vytvorenych souboru jsou spatne. Takze se mi nepovedlo prijit na to, jak namountovat samba sdileni tak, aby to fungovalo za kazdych okolnosti ve vsech aplikacich
Takze sambou to zrejme nepujde a budu se muset podivat po ostatnich resenich.
muzes vyzkouset smbmount?
#!/bin/bash
dir=/home/media/Fotky
group_owner=dospelaci
file_perm=660
dir_perm=770
acl_dir_perm=rwx
function unix_perms {
if [ `echo $retval | cut -d " " -f 4`="" ]; then
dir=$(echo $retval | cut -d "," -f 1)$(echo $retval | cut -d " " -f 3)
echo File: $dir : $retval
chmod $file_perm $dir
chown :$group_owner $dir
else
if [ `echo $retval | cut -d " " -f 3`="ISDIR" ]; then
dir=$(echo $retval | cut -d "," -f 1)$(echo $retval | cut -d " " -f 4)
echo $dir : $retval
chmod $dir_perm $dir
chown -R :$group_owner $dir
fi
fi
}
function acl_perms {
if [ `echo $retval | cut -d " " -f 3`="ISDIR" ]; then
# vytvoren/presunut adresar
dir=$(echo $retval | cut -d "," -f 1)$(echo $retval | cut -d " " -f 4)
acl_users=$(cat /etc/group | grep $group_owner | cut -d ":" -f 4)
acl_perm_part=$(echo $acl_users | awk 'BEGIN { FS="," } {for (i=1; i <= NF; ++i) {printf "u:%s:rwx", $i; if ( i < NF ){printf(",")}} printf("\n")}')
setfacl -m $acl_perm_part $dir
fi
}
while true;
do
retval=`inotifywait -f -r -e create -e moved_to $dir`
# acl_perms $retval
unix_perms $retval
done
Srdecne zdravim,
nejdrive bych rad shrnul problem, jak ho vidim ja.
Je treba vytvorit sdileny prostor s nasledujicimi vlastnostmi:
- vsechny soubory ve sdilenem prostoru musi byt dostupne vsem ostatnim, kteri maji povolen pristup, a to pro r/w nebo read only
- moznost definovat skupiny uzivatelu pro jednotlive prostory a jestli jsou pro tohoto uzivatele r/w nebo read only
- moznost kopirovat/presouvat soubory prostym volanim prislusneho prikazu, tedy bez volani chmod ci chown uzivatelem (aby to zvladla sekretarka) a to i z domovskeho adresare na sdileny disk (jiny vlastnik, skupina a prava)
- na pocitaci pracuje vice lidi najednou, kazdy smi pouze do nadefinovanych prostoru.
Jak na to? Ve foru zaznelo:
umask: Nevyhovuje, nenastavuje nic krome prav. Navic bezpecnostni riziko jine soubory.
Samba a NFS pres localhost: Bud jsou nebo nejsou namontovane. Nevyhovuje pro viceuzivatelsky rezim.
ACL: Castecne jsem to rozchodil, ale neumim vyresit problem zakladani novych adresaru - vzdy dostanou vlastnika a skupinu podle zakladatele. Mozna to jde nejak resit, pokud to nekdo zvladate, ozvete se.
inotify: Vyzkousel jsem skriptik s inotifywait, coz nadherne funguje a vyhovuje to vsem bodum podle zadani. Ma to hacek - nestiha to. Provedl jsem test ve sdilenem adresari: for ((i=0;$i<100000;i++)) do touch $i; done a dopadlo to tak, ze spravne melo prava a skupinu pouze asi 5 procent souboru. Ano, mel jsem to prepsany do perlu, ano, slo by to napsat v cecku, ale neverim, ze by to vedlo ke stoprocentnimu vysledku.
Pravidelne nastavovani vlastnika a prav kazdych N sekund: Zcela funkcni, ale vytezujici stroj, a vubec, tohle je fakt osklive. Nehlede na to, ze uzivatele jsou nuceni obcas cekat na provedeni zmen.
Nabourat jadro: Zatim jedina mne znama cesta, ktera vede k cistemu vysledku. Neznate nejake rozjete projekty v tomto smyslu?
Zdravi
Jiri Smitka
Zatim jsem to vyresil pres lokalni Sambu montovanou pri bootovani do domovskych adresaru jednotlivych uzivatelu, kazdemu podle jeho prav.
Funguje to a splnuje to snad vsechny uvedene podminky.
Zdravi
Jiri Smitka
Nevyhovuje to napr. v situaci, kdy jedna skupina uzivatelu ma mit plny pristup, druha skupina pouze pro cteni a treti vubec zadny. Jinak je pravda, ze pro sdileni filmu atd. to bohate staci. Pro sdileni ruzne utajovanych informaci jiz ale ne.
Zdravi
Jiri Smitka
Tiskni
Sdílej:
ISSN 1214-1267, (c) 1999-2007 Stickfish s.r.o.
5.8.2006 20:51