Üdv!
Következőt szeretném megoldani unix-szerű rendszeren:
Van egy (vagy több) adminisztrátorom.
Van több felhasználóm, mindegyiknek egy home könyvtára.
Van több adat könyvtáram, amiben adatok vannak, ezek nem a felhasználók könyvtárai.
Minden felhasználó írhatja-olvashatja a saját könyvtárát.
A felhasználóknak be van állítva néhány adat könyvtár aminek olvashatja a tartalmát. Minden felhasználónak egyedi ez a beállítás.
Az adminisztrátor minden felhasználó könyvtárát, és az adat könyvtárakat írhatja-olvashatja.
Az adminisztrátor nem root, és a rendszerből nem láthat mást csak a felhasználók home könyvtárait, és az adat könyvtárakat.
Milyen csoportbeállítás trükköket kell alkalmaznom ahhoz, hogy ezt felállást megvalósítsam?
- 2393 megtekintés
Hozzászólások
"Az adminisztrátor nem root, és a rendszerből nem láthat mást csak a felhasználók home könyvtárait, és az adat könyvtárakat."
Ezt pontosan hogy érted? Mert a rendszer könyvtárakat mindenki látja (pl. szép lenne, ha a /bin, /usr/bin, ... könyvtárakat se a userek, se az adminok nem látnák).
Amúgy én így csinálnám:
1. megoldás (hagyományos): Minden adat könyvtárnak más csoport lenne a tulajdonosa (pl. data_1, data_2, stb. csoportok) és a felhasználókat abba a csoporttokba venném bele, amelyik adatkönyvtárnak olvashatják a tartalmát. Nem tudom, hogy azt hogy lehetne megadni, hogy az adminok csoportja írhatja... (egy admin felhasználó esetén ő lenne a tulaja a könyvtárnak)
2. megoldás: acl használata
- A hozzászóláshoz be kell jelentkezni
"Ezt pontosan hogy érted? Mert a rendszer könyvtárakat mindenki látja (pl. szép lenne, ha a /bin, /usr/bin, ... könyvtárakat se a userek, se az adminok nem látnák)."
Tisztán elméleti síkon értem, most vonatkoztassunk el a rendszerkönyvtárak látványától. (ftp felhasználók lesznek, shell account nélkül)
- A hozzászóláshoz be kell jelentkezni
Ebben az esetben a felhasználókat zárd be a saját home-jukba, majd csatold be pl. a /mnt alá azokat a könyvtárakat, partíciókat, amelyeket mindenki láthat, s mountold őket újra (tehát egyszer már be lehetnek csatolva) a "bind" kapcsolóval. Így a home könyvtárakból tudsz szimlinket csinálni az adott könyvtárakra, de asszem kilépéskor a home-ba jutnak vissza. A többieknél már csak a megfelelő csoportokat kell meghatároznod.
Spec. ez működik olyan helyen (is), ahol van 3-4 ember, de mindegyikük garázdálkodni akar a szerveren lévő www könyvtárba/-ban/-ból, s így egyszerűbbnek tűnt (akkor), mint mindenki írkáljon a saját könyvtárába, aztán majd pl. óránként szinkonizáltatok egy scripttel.
- A hozzászóláshoz be kell jelentkezni
Bindmount-ra gondoltam az elején, mert az volt a legkézenfekvőbb és legegyszerűbb. De nekem úgy tűnt, hogy egy idő után kezelhetetlenné fog válni. Itt tartósan 200-300 user lesz, és naponta kell kiszedni, hozzáadni, módosítani, amivel viszont senki hozzábbértőnek (és kevésbé hozzábbértőnek se) nem lesz ideje foglalkozni.
Pont a nagy user szám miatt, nem tudom mennyire egészséges egy filerendszerben 1000 körüli mountolás, illetve nem tudom mi történik rendszerújrainduláskor, kell-e rögzíteni a mountokat az fstab-ban, ha igen azt is adminisztrálni kell scriptből... Csúnya.
Persze cáfoljon meg aki tud, én hajlok erre, ha valaki tud mutatni működő példát, ami nem túl gyakran omlik össze. Nekem mindenesetre nem tűnik jónak.
- A hozzászóláshoz be kell jelentkezni
Az fstab-ban lehet rögzíteni, de írhatsz rá egy scriptet is, ami az ftp-szervered induláas előtt csatolgatja a meghajtókat.
A felhasználók hozzáadását/módosítását/törlését esetén viszont semmi pillanat alatt meg tudod oldani scriptből, ami létrehozza a felhasználót a könyvtárával, megadja a jelszót is (pl. felolvassa egy fájlból vagy mittomén), aztán elkészíti a linket.
De ez csak egy tipp, lehet, hogy egy LDAP-jellegű felülettel sokkal előrébb tudsz jutni.
- A hozzászóláshoz be kell jelentkezni
Megnéztem mi ez az acl... Első körben a hagyományos módszert preferálnám.
- A hozzászóláshoz be kell jelentkezni
Üdv. Remélem nem mondok hülyeségeket.
>Van egy (vagy több) adminisztrátorom.
/etc/passwd-ben, a 0. sorszámú felhasználó a rendszergazda
ergo átnevezheted pistikére is, illetve lehet több 0. sorszámú usered is.
azaz
root:0
pistike:0
azért nézd meg a sudo parancsot, hátha e helyett az is jó arra amit szeretnél
>Van több felhasználóm, mindegyiknek egy home könyvtára.
>Van több adat könyvtáram, amiben adatok vannak, ezek nem a >felhasználók könyvtárai.
>Minden felhasználó írhatja-olvashatja a saját könyvtárát.
Eddig sima ügy
>A felhasználóknak be van állítva néhány adat könyvtár aminek >olvashatja a tartalmát.
>Minden felhasználónak egyedi ez a beállítás.
csinálj csoportokat, /etc/groups , egy felhasználó per csoport, adott könyvtárra a csoport csak olvashat
>Az adminisztrátor minden felhasználó könyvtárát, és az adat >könyvtárakat írhatja-olvashatja.
Szintúgy alap beállítás, ez a default
>Az adminisztrátor nem root, és a rendszerből nem láthat mást csak a >felhasználók home könyvtárait, és az adat könyvtárakat.
Akkor nem is adminisztrátor??
admin nem root: ld első pont, a root:0 sort kiveszed a /etc/passwd-ből, és a pistikét benne hagyod
bár erre is a sudo lehet az amit keresel
- A hozzászóláshoz be kell jelentkezni
Nem, ez a megoldás biztosan nem járható, nem akarom, hogy az adminisztrátor turkáljon és kolbászoljon a rendszeremben. A kolbászturkász az a root.
- A hozzászóláshoz be kell jelentkezni
Hmm.. talan ezt lehetne...
-rwxrwx--- 1 user1 admins 4096 Jan 13 2005 home1
-rwxrwx--- 1 user2 admins 4096 Jan 13 2005 home2
-rwxrwx--- 1 user3 admins 4096 Jan 13 2005 home3
-rwxrwx--- 1 user4 admins 4096 Jan 13 2005 home4
-rwxr-x--- 1 admin data1 4096 Jan 13 2005 data1
-rwxr-x--- 1 admin data2 4096 Jan 13 2005 data2
-rwxr-x--- 1 admin data3 4096 Jan 13 2005 data3
>groups user1
>data1 data2
>groups user2
>data1 data3
>groups user3
>data2
>groups user4
>data1 data2 data3
>groups admin
>admins
Azaz, a user konyvtarak az admins group ala tartoznak, akinek rw joga van, a data konyvtarak meg a data1, data2 .. stb csoportba. Minden usert hozzaadsz azokhoz a data# csoportokhoz is amelyik konyvtarakat lathatjak. A data konyvtarakra a csoportnak r-- joga van. A data konyvtarak tulaja, viszont az admin, es irhatja olvashatja. Az admin benne van az admins csoportba, igy irhatja olvashatja a user-ek konyvtarait is...
Negativumok: igy normalisan csak egy admin van. Ha a user szorakozni akar, akkor meg tudja vonni a jogokat a sajat konyvtarara az admintol...
Tobb admin... letre lehet hozni azonos UID-el tobb usert, de ez csak annyi kulombseggel jar, hogy a kulombozo adminoknak kulombozo home konyvtaruk, shell-juk ill. jelszavuk lehet, amugy teljesen egyformak (jogosultsagokra, mivel a jogok UID-hez kotodnek, nem nevhez :-))
A user ne tudjon szorakozni: nem ove a home konyvtar, hanem az admin-e, igy nem tud jogokat piszkalni. a home konyvtarak meg valahogy igy neznek ki:
-rwxrwx--- 1 admin home1 4096 Jan 13 2005 home1
-rwxrwx--- 1 admin home2 4096 Jan 13 2005 home2
-rwxrwx--- 1 admin home3 4096 Jan 13 2005 home3
-rwxrwx--- 1 admin home4 4096 Jan 13 2005 home4
A user-ek, meg meg hozza vannak adva az adott home# csoporthoz is. pl.:
>groups user1
>home1 data1 data2
Zsiraf
- A hozzászóláshoz be kell jelentkezni
Igen, valami ilyesmire jutottam én is. Azért ez elég bonyolult, főleg adminisztrálni, felvenni új user-t, törölni usert, mondjuk mindezt megírni script-ből... De ez tűnik az egyetlen módszernek. Azt reméltem lesz valami teljesen triviális és egyszerű megoldás, ami az acl lenne ezek szerint, de nem vagyok benne biztos, hogy a rendszeremen könnyedén megvalósítható a támogatása, illetve van némi ellenérzésem vele kapcsolatban.
- A hozzászóláshoz be kell jelentkezni
Milyen rendszer és milyen ellenérzés?
- A hozzászóláshoz be kell jelentkezni
Sarge és szubjektív.
- A hozzászóláshoz be kell jelentkezni
"A user ne tudjon szorakozni: nem ove a home konyvtar, hanem az admin-e, igy nem tud jogokat piszkalni."
Bocs, ha felrebeszelek, mert igazabol nem vagyok admin, de amit te ajanlasz az szerintem csak addig ved, amig el nem dugja egy alkonyvtarba amit akar. Utana mar o az owner...
- A hozzászóláshoz be kell jelentkezni
Ja, ez igy van...
Zsiraf
viszont ezt a POSIX ACL-el se lehet kivedeni, ha jol tudom :-(
- A hozzászóláshoz be kell jelentkezni
A könyvtárra beálltott default ACL esetén ki lehet, nem?
- A hozzászóláshoz be kell jelentkezni
Előre is elnézést ha hülyeség... A szokottnál is álomkórosabb vagyok ;)
Az ACL használat itt ágyúval verébre kategóriába tartozna?
Vagy a filerendszered nem ismeri?
--------------
Fel! Támadunk!
- A hozzászóláshoz be kell jelentkezni
Nem tudom, hogy neki milyen fájlrendszere van, de pl. ext2/3 esetén nem tekinteném ágyúval verébre kategóriának, mert eléggé le van egyszerűsítve ahhoz, hogy gyors és hatékony legyen. A másik véglet pl. az ntfs acl-jei, amik már viszont ágyúval verébre kategóriába esik. Most nem az ext2-t vagy az ntfs-t akarom leszólni. Egyszerűen más megközelítéseket használnak és így másra is jók.
- A hozzászóláshoz be kell jelentkezni
ntfs-t kizárólag windows-ból piszkálgatnék ilyen szinten.
Onnan meg nem túl bonyolult. ;)
--------------
Fel! Támadunk!
- A hozzászóláshoz be kell jelentkezni
Ugye nem lesz most itt ebből flame?
- A hozzászóláshoz be kell jelentkezni
Nem annak szántam. Komolyan gondoltam, hogy ntfs-t linux alól nem szívesen használok - leszámítva a read only üzemmódot.
Viszont a jogosultságkezelést ha windows-ból intézem, akkor viszonylag egyszerűen, kultúráltan meg lehet oldani (legalábbis azon a szinten ahol nekem szükségem van rá)
--------------
Fel! Támadunk!
- A hozzászóláshoz be kell jelentkezni
Ezen a részen épp ext2 van a rendszeren. Szóval file-rendszer szempontból menne az acl, csak a nemtommiezéshogyműködik effekt illetve a nemtomtudjaeakernelem effekt miatt hanyagolnám. Amúgy igen, acl-el tök jól megoldható lenne.
- A hozzászóláshoz be kell jelentkezni
Kipróbáltam, nem támogatja a kernelem az acl-ot. Most nem cserélnék emiatt kernelt, ha van más megoldás is.
- A hozzászóláshoz be kell jelentkezni
Láttam, hogy sok user, napi szinten változások. Mindenképp az acl-t javaslom. Itt egy leírás az ext2 által is támogatott acl-ről (posix):
http://www.suse.de/~agruen/acl/linux-acls/online/
Hányas kernel, hogy még nem tudja? vagy csak nincs beleforgatva?
A fájlrendszeren így tudod bekapcsolni:
tune2fs -o acl /dev/akármi
Az acl információkat attribútumként tárolja, max 32 acl bejegyzés lehet egy fájlon/könyvtáron.
Esetleg még gondolkozhatsz más szinten megvalósított ACL-ben, vagy szabály alapú hozzáférés vezérlésben (RBAC Rule Based Access control). Pl. az ftp kiszolgálóba beépítve, biztonsági bővítményként a rendszerre, stb. Ezekben sajnos nem tudok segíteni.
- A hozzászóláshoz be kell jelentkezni
Mar bocs, nem az ACL-ek ellen beszelek, de nem ertem, miert jobb az mindenkepp??? Mitol "egyszerubb" ott megvalositani? Ha ott felveszel uj felhasznalot, ugyanugy be kell jegyezni a megfelelo helyekre... Nem ertem ... :-o
Zsiraf
p.s.: az ACL szerintem akkor kell, ha nem tudod a "hagyomanyos" modon megoldani...
p.s2: a kezelesre meg irni kell egy scriptet akarmiben (perl, python, tcl, ...), akarmilyen felulettel (semmi, dialog, tk, gtk, ...) ami a monoton munkat megcsinalja ... nem latom azt a borzalmas bonyolultsagot, amit raadasul az ACL-ek "levennenek" a valladrol
p.s3: amugy nem lehet, hogy jobb ezt az ftp szerver keretein belul megvalositani? Pontosan nem tudom, de pl. a Pure-FTPd is tud "virtual" user-t.. ???
- A hozzászóláshoz be kell jelentkezni
Unixos ACL-t csak hírből ismerem. VMS-en gyártok egy azonosítót, azt beírom az ACE-be és az azonosítót adom azoknak a usereknek akiknek jogot akarok adni az adott objektumra.
Már nem emlékszem, hogy mi a helyzet unix like rendszeren - ha van lehetőség x groupnak jogot adni, akkor leginkább group-nak adnék jogot és az illető groupba venném fel a usert.
szerk: viszont egy óriási hátránya lehet, hogy lassítja a file rendszer kezelését ami bizonyos esetekben már zavaró is lehet.
--------------
Fel! Támadunk!
- A hozzászóláshoz be kell jelentkezni
Szerintem, nem ez a problema, hiszen a nem ACL-es megoldas is arrol szol, hogy csoportokba kell berakni a usereket (usermod -G group1,group2,... user1).
A problema szerintem az lehet, ha minden user kulonfele csoportokba leledzik, ilyenkor nagyon sok -Gxxx,xxx,xxx-et kell beirni... De ugyanez az ACL-eknel is megvan, hiszen alapvetoen az is a user:group:other->rwx-re epit, a kulombseg csak annyi, hogy tobb "user" es "group" is lehet... Am ha 200-300 userrol van szo, es elegge vegyes salata, akkor nagyon konnyen kifut az ember abbol a max 32 ACL-bol, tehat ott is marad a group-os buli, akkor meg ugyanott vagyunk, ahol a part szakad...
A tobbi meg csak a korites, eleg hamar ossze lehet utni akarmilyen script-et, ahol a klikk-klikk-klikk modszerrel "kenyelmesen" lehet usert felvenni torolni, modositani...
Zsiraf
p.s: Nem akarok az ACL-ek ellen beszelni ;-) de ext2-on a baratunk altal emlitett linken, arrol van szo, hogy cache nelkull kb. 200x lassabb az adott file eleresi ideje (nem az olvasasi/irasi!!!)
- A hozzászóláshoz be kell jelentkezni
160 GB-os megosztást üzemeltetek acl-lel. Semmi nem tűnt fel az acl bevezetésekor. Mondjuk olvasási cache nélkül ki használ fájlrendszert? Amúgy annyi történik, hogy a jogosultságkezelő bitek helyett egy attribútumot kell kiolvasnia, ami max pár tíz bájt méretű.
Az acl ebben a példában csak azért kell, mert az adminoknak már nem tud külön csoportot beállítani a könyvtárakon.
A 32 bejegyzés meg bőven elég kell, hogy legyen. Ebben a példában két bejegyzésre van szükség: admin csoportnak teljes jog és a data_x csoportnak olvasási jog. Utána egyszerűen a megfelelő csoportok tagjaivá kell tenni a fejhasználókat.
De említettem azt is, hogy talán nem is fs acl-ben kéne gondolkodni, hanem pl. ftp kiszolgáló jogosultságkezelő rétegével (ha van). Pl. samba-nál simán megoldható ez a probléma az smb.conf-ban, ha minden egyes adatkönyvtár külön megosztásként szerepel.
- A hozzászóláshoz be kell jelentkezni
Az attributum egesz mashol van, mint a file, illetve az inode, mivel oda mar nem ferhetett, tehat minden egyes file-elereskor ket helyrol kell olvasnia... ez teheti lasabba. Ez persze a sok kicsi file eseten lehet jelentos... Ha tavolrol ftp-zik, akkor valoszinu sose veszi eszre, mivel a net sebessege joval kisebb...
Az acl ebben a példában csak azért kell, mert az adminoknak már nem tud külön csoportot beállítani a könyvtárakon.
Amit te ajanlasz, az semmiben nem kulombozik a "hagyomanyostol", s ahogy felvazoltam, az adminok is kivitelezhetok. Mivel ftp eleresrol van szo, shell es egyeb nelkul, valoszinu, hogy semmi hatranyat nem erzi annak, hogy ugyanazon uid alatt vannak az adminok. Habar az eredeti felvetesben, a tobb admin opcio volt...
A problema szerintem abban all, hogy itt sok kulombozo jogosultsagu felhasznalo van viszonylag keves konyvtarral, s nem a forditottja. A jogosultsag kezeles, viszont file oldalrol indul es nem user oldalrol, azaz azt tudod megmondani, hogy az adott file-al ki mit csinalhat, nem pedig azt, hogy az adott felhasznalo mely file-al tehet ezt, vagy azt. Ez a szemleletmod, egyarant ervenyes az eredeti jogkezelesre es az ACL-ekre is...
A legegyszerubb az lenne, ha nem lenne a harmincket bejegyzeses korlat, es igy az uj felhasznalot felhasznalokent hozza lehetne adni az adott file/konyvtar jogosultsagaihoz... de nem ez a helyzet...
Zsiraf
p.s.: Nem vagyok az fs acl ellen, csak arra akartam felhivni a figyelmet, hogy a fenti problema megoldhato kb. ugyanolyan bonyolultsagi szinten a "hagyomanyos" jogokkal is :-) (az acl eseten sem ussza meg a sok csoportba betuszkolast...)
p.s2: ez mar tenyleg csak sajat velemeny: az ACL manapsag hasonlo divat, mint a java/php/oo/flash/xml/.. stb. Forradalmian ujat egyik se hozott, viszont mindegyik vilagmegvaltokent van/volt/lesz beharangozva, s mindenhol probaljak hasznalni ha kell, ha nem ;-)
p.s3: mindenkepp egyetertek abban, hogy megerne utannanezni az ftp-szervereknel a dolognak, hatha van kezreallobb megoldas...
- A hozzászóláshoz be kell jelentkezni
> Hányas kernel, hogy még nem tudja? vagy csak nincs beleforgatva?
Debian 2.4.27-3-686-smp #1 SMP Wed Feb 8 12:27:28 UTC 2006 i686 GNU/Linux
A debian konfig file szerint be van kapcsolva mégis azt mondja a setfacl-ra, hogy a művelet nem támogatott. Tune2fs-el bekapcsoltam az acl-t a partíción.
- A hozzászóláshoz be kell jelentkezni
Részemről passzolok. Én 2.6-ossal próbáltam először ki.
- A hozzászóláshoz be kell jelentkezni
őőőőőőőőő, most nem olvasom végig, de ha jól emlékszem, kell a mount -nak egy "-o acl" paraméter, vagy az /etc/fstab -ba
(ha már valaki írta, akkor bocs)
- A hozzászóláshoz be kell jelentkezni
Én is így emlékszem, de már keverem a hpux-solaris-linux-freebsd rendszereket... :)
--------------
Fel! Támadunk!
- A hozzászóláshoz be kell jelentkezni