[Megoldva] Egyetlen file törölhetetlenné tétele hogyan?

 ( locsemege | 2015. október 7., szerda - 15:22 )

Van egy alkönyvtár, abban több file. Ezek közül egyet törölhetetlenné kellene tenni. A filerendszer ext4.

Az alkönyvtár többi file-ját kell tudni törölni, tehát a tartalmazó alkönyvtárra kell írási jog. Minden file-t kell tudni módosítani, így az immutable flag nem jó.

Van erre megoldás? Sima user jogú alkalmazásnak kell tudnia nem törölni az érintett egy file-t.

Update

Köszönöm mindenkinek a segítséget, együtt gondolkodást. A bind mount önmagára nagyszerű ötlet, elrakom az emlékezetembe. Végül a Claws-Mail kliens használata mellett döntöttem, ebben a jogok állíthatók.

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

Egy chmod 400 nem elég? Vagy én nem értek valamit?

Egy könyvtárban a file-ok törölhetőségét a könyvtár és nem a file jogosultsága határozza meg. Alap unix jogosultságkezelés esetén persze.

Ave, Saabi.

De. chmod 500 a tartalmazó mappára.
--
Coding for fun. ;)

"Az alkönyvtár többi file-ját kell tudni törölni, tehát a tartalmazó alkönyvtárra kell írási jog."
--
Blog | @hron84
Üzemeltető macik

Ja, én se voltam elég figyelmes. :D Szerintem ezt így nem lehet megcsinálni.
--
Coding for fun. ;)

chattr +i filename

--
trey @ gépház

Nem jó, mert írni azért kell.
--
Coding for fun. ;)

"így az immutable flag nem jó"

Ja, látom. Nem olvastam végig.

--
trey @ gépház

chattr +a egyetlenfile.txt

# rm -f egyetlenfile.txt
TILOS

# mv egyetlenfile.txt valamimas.txt
TILOS

# echo "uj adat" > egyetlenfile.txt
TILOS

# echo "extra adat" >> egyetlenfile.txt
ENGEDÉLYEZETT

Bár valószínűleg ez az írási mód nem fogja kielégíteni a kérdező igényeit. Hozzáírni lehet, törölni nem, módosítani a meglevő fájltartalmat nem.

Szerintem azért nincs implementálva ilyen funkció mert nincs sok értelme. Ha lehet módosítani a fájl tartalmát, akkor ezzel ki lehet törölni mindent amit tartalmaz, csak maga az üres fájl marad meg. Akkor pedig miért ne lehessen törölni?

Vótmá', és el lett magyarázva miért nem jó.

Bocs nem olvastam végig minden hozzászólást.

Akkor ez a tipp már csak a hajónaplónak ha valakinek hasonló problémája van és a cél csak a fájl visszanyerése véletlen törlés esetén: Btrfs snapshot funkciója jó a törölt fájlok visszanyerésére még van elég hely a háttértáron.

Hogy akadályoznád meg azt, hogy 0 bájtosra írja az user a fájlt? Az már egy fél törlés. ;)

Nem, mert ha 0 byte-ra írja az alkalmazás a file-t, annak jogai nem változnak meg. Ha viszont törli, majd létrehozza, akkor a tulajdonos az lesz, akinek a nevében fut a process, aki létrehozta.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nagyon sok ilyen fájl van vagy csak néhány?

Mert ha nincs rengeteg akkor talán elég ha folyamatosan fut egy script a háttérben ami módosítja root-ra vagy arra a userre akire akarod az adott fájlok tulajdonosát és a jogokat eredeti állapotra.
Ha törölve lett és újra létrehozva akkor is visszaállnak az eredeti jogok.
Illetve érdemes úgy megírni, hogy előbb megnézi a fájl jogait és ha nem az aminek lennie kell akkor módosítja.

http://hup.hu/node/143117#comment-1914021

Szerintem mar megoldottam. Csak senki nem gorget le oda...

Azaz előbb csináljon sudo mount -o bind notdeletable notdeletable... paranccsal helyet az írható de törölhetetlen fájloknak majd linkelje onnan abban a könyvtárba a fájlokat ahol használatban vannak. Így értetted igaz?

Ezt a "notdeletable" opciót még eddig nem ismertem.

nem.
Ugy ertem van egy fileod, xyz, es azt mondod neki, hogy
sudo mount -o bind xyz xyz

Felul bind mountolod a file-t az eredetivel, igy nem lehet torolni, mert meg hasznalatban van.

Ubuntu-n mukodik, de gondolom mindenhol ahol van bind mount.

Huhh, így végre érthető, mert már akartam kérni, hogy magyarázd meg, hogy mit is akarsz csinálni.

Az ötlet nagyon szellemes, és ha még működik is (mármint az adott helyzetben), akkor grats :-) (Kipróbálva, valóban a kívánt eredményt kapom, de a jó isten se tudja mit trükközik a TB :-) )

:) ettol meg egyet ertek egy korabbi hozzaszolassal, hogy mar design-nal gondok lehetnek... Ekkora hack-et nem szivesen hasznalnek production-be...

Ez egy piszok jó trükk!
Production-be valóban megfontolandó az alkalmazása. Bár annyira alapszolgáltatásra épül, hogy valószínűleg ott is működik.
A script viszont biztosan jó és használható is, ha nincs millió ilyen típusú védendő fájl. Millió fájlnál is működik csak túl sok erőforrást igényelne a folyamatos pásztázásuk.

A scripttel az a baj, hogy lesznek időben lyukak, amikor éppen rossz lehet, bár mivel egyszerre egy user lép be, a konkrét esetben ez nem probléma.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem az inotify nem zabal olyan sokat sok file-nal sem, de nem csinaltam ra meg tesztet...

En meg megemlitettem az incron-t (ami az inotify cron megfeleloje, inotify esemenyre lehet scriptet kotni), csak elsikkadt... :-)
--
Blog | @hron84
Üzemeltető macik

Én is említettem, de ez a mount --bind max pontos workaround szerintem.

Mindenki a fájlszintű jogosultságok körül keresgélt, de a megoldás máshol volt. Gratula!

A megoldas az, hogy a jelenlegi kornyezetben nincs megoldas. Ha a kerdeses fajl nem mozgathato onallo almappaba (gondolom nem), es irhatonak kell maradnia, akkor nincs megoldas a problemadra POSIX jogosultsagszinten.

Sajnalatos modon a modern Linuxok meg mindig az elavult POSIX jogosultsagkezelest hasznaljak, ami nem ertelmezi a fajlletrehozast es -torlest kulonallo muveletkent, azt az irasi muvelet reszekent kezeli, csak az ertelmezes targya mas (a tartalmazo mappa). Parszor en is szembesultem mar azzal, hogy ezen korlatok miatt bizonyos feladatok megoldhatatlanok a kornyezet jelentos megvaltoztatasa nelkul, tenyleg jobb lenne, ha atvennenek valami modernebbet mar, pl. az NTFS jogosultsagrendszeret.
--
Blog | @hron84
Üzemeltető macik

Az igazsághoz hozzá tartozik, hogy a törlés tiltásának nincs sok értelme, ha egyébként írás jogosultság van, mert lazán nullára lehet tenni, kissé false sense of security lenne. Appenddel éppen lenne értelme (tényleg, locsemege +a nem játszik?), de az meg gyak magában foglalja, hogy nem lehet törölni, kár hozzá külön flag.

A false sense of security-vel egyetertek, ha es amennyiben ezt a jogosultsagot a tartalom vedelmere hasznalnank, de itt alapvetoen nem biztos, hogy errol van szo.

Altalanossagban a torles tiltasanak jogat kifejezetten az accidental deletion jelenseg megelozesere hasznaljak, ugyanis veletlenul is osszefoghatod tobb fajllal, es az "are you sure" kerdesre eleg sokan vakon nyomkodjak az "Igen, mindet" gombot. Ilyen ertelemben viszont hasznos egy kulon flag.
--
Blog | @hron84
Üzemeltető macik

Igen, ez nálam belefér a nincs sokba.A jogosultságkezelés alapvetően egy authorizációs framework, és leginkább a security requirementek kezelése a dolga, nem tudom jó ötlet-e user önvédelmi mechanizmusokat belekeverni. (Tudnék érvelni pro & contra)

Ertelmezes kerdese, mi tartozik a security fogalmaba. Ha van egy fontos dokumentumom, amit szeretnek, ha a titkarno nem tudna veletlenul kitorolni, akkor az akar oda is tartozhat.
--
Blog | @hron84
Üzemeltető macik

Azért ez elég unortodox értelmezés...

A POSIX jogosultságkezelés + ACL kb. mindenre elég. Ami ennél komplikáltabb, azt elrontották, lehet újratervezni.

Ave, Saabi.

A frászt. Amíg nem implementálják fájlrendszer-szinten az öröklött jogokat, addig a Linux tökéletesen alkalmatlan fájlkiszolgálónak1

Az öröklött jogok alatt nem a create maskot vagy default ACL-t kell érteni. Azzal ugyanis csak azt tudod meghatározni, hogy a megadott helyen az új fájl/könyvtár milyen jogokkal jöjjön létre, de ha van egy fájlrendszered mondjuk 15 millió fájllal, akkor ahhoz, hogy egy júzer/csoport számára hozzáférési jogosultságot módosíts mindenre, ahhoz rekurzíót kell használnod, ami ennyi inode esetében órákig/napokig tarthat IOPS teljesítmény függvényében, arról nem is beszélve, hogy mivel minden fájl önmaga hordozza az ACL-eit, ezért roppant könnyű inkonzisztens állapotot létrehozni. (Találd meg, hogy hol mi miért nem írható Pistike által, holott elvileg korábban rekurzívan adtál jogot az egész fára)

Valódi öröklődés esetén 1 helyen (a kívánt faág tetején) beállítod az ACL-t, és minden, ami alatta van, az úgy viselkedik, ahogy kell. Ha pedig egy al-bejegyzésen más kell, akkor ott és akkor szintén egy darab bejegyzéssel elvágod az öröklődést.

Ilyet Linuxon, támogatással rendelkező2 free szoftverek segítségével ismereteim szerint csak Samba-val tudsz csinálni, ahol a jogosultságkezelést nem a kernel/filerendszer, hanem maga a Samba service oldja meg. Magyarul, localhost-on is csak úgy működik, ha a localhostról felmountolod a megosztást cifs-en.

A Samba pedig közismerten nem egy kapkodó vadállat.

Jelenleg Linux-on Novell NSS fájlrendszert használok. A meglehetősen komplex, sokszáz felhasználós rendszer összes trustee ACL-je elfér egy pár kByte-os, átlátható, központilag szerkeszthető fájlban, és akár XML interfészen keresztül is módosítható.

1 Ha fájlkiszolgáló alatt nem Samba-t/CIFS-t értünk.

2 Egyszer valaki elkezdte implementálni a Novell-féle trustee-rendszert Linuxra, de IMHO az legalább egy évtizede elhalt projekt volt.

... vagy, lemaradtam volna valamiről?

és minden, ami alatta van

Az a baj ezzel, hogy koncepcionálisan nem kompatibilis az "alatta van" az "inode + link" megoldással. Mármint elvi síkon... Ugyanis egy inode több könyvtár "alatt" tud lenni egyszerre. Én is imádtam anno a PC-s világban a Novelles jogosultságkezelést, maga volt a kényelem netovábbja. De sajnos nem lehet értelmesen összehozni ezzel. És senki nem óhajt a POSIX fs szemantikáról váltani azért, hogy ilyen jogosultsági rendszere lehessen. Azt el lehet játszani, mint a Sambával is, hogy egy user-space program implementálja a jogosultságokat az export számára, de a gépen belül az ugye nem érvényes.

> Az a baj ezzel, hogy koncepcionálisan nem kompatibilis az "alatta van" az "inode + link" megoldással.
> ...
> És senki nem óhajt a POSIX fs szemantikáról váltani azért, hogy ilyen jogosultsági rendszere lehessen.

Nem osztom ezt a véleményt. Felhasználói (és fájlszerver adminisztrátori) szemmel cseppet sem érdekel senkit, hogy a motorháztatő alatt inode-ok és linkek vannak, vagy éppen kismókusok. Azt tudom, hogy POSIX ACL-ekkel vért izzadtunk, hogy normális hozzáférés-szabályozást csináljunk (sokfelhasználós, komplex rendszerekről van szó!) míg Netware+NSS, OES+NSS és Windows+NTFS alatt minden megy, mint a karikacsapás. Ki is dobtuk a natív POSIX megoldásokat, nagyon gyorsan.

A SUSE Linuxon futó Novell NSS egy nagyszerű termék. Ha valaki implementálja opensource alapon, már küldöm is paypalon a támogatást.

Az NSS kifelé POSIX környezetet (is) emulál. Lehet virtuális inode-okat fstat()-olni, ha valakinek épp arra van gusztusa.

A POSIX ACL-nek megvannak a korlátai, ez tulajdonképpen köztudott, de az elérhető RBAC megoldásokkal mi baj? Még válogatni is lehet.

Melyik RBAC implementációval és hogyan valósítanád meg az öröklött jogokat egy POSIX fájlrendszeren?

Nem szoktam ilyet csinálni, de selinuxban pl a file typera ad külön unlink permissiont, ami ennek a kontroljára való, a kontextusok pedig alapból öröklődnek, uh így első bliccre nem tűnik nagy vasziszdasznak egy megfelelő allow rule, illetve a rootdir megfelelő contextbe tétele. Aztán lehet, hogy van benne elrejtve benne csont, illetve ez nyilván nem a POSIX jogokat örökölteti.

Ahham, csakhogy az RSBAC egyaltalan nincs tamogatva egy disztro alatt sem. Ismeros tolta a Mandrivanal, hogy legalabb egy disztro legyen, ami ilyen kernelt szallit - aztan megszunt a Mandriva, mint olyan.

Akkor mar inkabb SELinux.
--
Blog | @hron84
Üzemeltető macik

Ez olyasmit jelentene, hogy bármely fájlmegnyitás előtt felmászik a path-on a gyökérig, és minden ponton ellenőrzi, hogy van-e ott valami örökletes jogosultság beállítva? Hogyan kombózik ez a szoft- és hardlinkekkel?

Igen, kb így kell elképzelni. A linkekkel úgy bánik ahogy ebből kifolyólag elvárható (soft link: mindkét útvonalhoz kell hozzáférés, hard link: elég az egyik útvonalhoz hozzáférés).

Sajnos ez a kismókusosdi csak addig nem érdekel, amíg minden szép és jó, minden működik. Ez kb. addig igaz, amíg csak fájl szervernek akarod használni, azaz nem akarsz natív UNIX alkalmazásokat futtatni. Mert ők az egyetlen ismert szemantikára építenek, és ha nem azt kapják, akkor random dolgok nem fognak jól működni - és ezért már a felhasználó is morcos lesz. Ha viszont csak fájl szervernek kell, akkor meg a kismókusosdi szerint miért is nem mindegy, hogy a kernelben van implementálva a jogosultság, vagy mondjuk a Sambában? Hiszen meg lehet ezt csinálni user-space szinten is, legfeljebb akkor van gond, ha valaki hátulról is hozzányúl a fájlokhoz.

> miért is nem mindegy, hogy a kernelben van implementálva a jogosultság, vagy mondjuk a Sambában?

Egyszer hasonlítsd össze egy localhoston felmountolt samba teljesítményét egy sima helyi fájlrendszer teljesítményével...

Ez mennyiben releváns a kérdésben? Ha mindenképpen kell a Samba, akkor nem mindegy, hogy rakunk bele még egy plusz jogosultságellenőrzést is? Hiszen arról volt szó, hogy nem UNIX (tehát nem a localhost) a kliens...

Az én threademben nem volt arről szó. Nálam Linux a kliens is, és localhoston is szeretném az öröklött jogokat. Cseppet sincs szükségem Samba-ra.

Bakter, de a hozzászólásomban, amire válaszoltál, erről volt szó!!!!!

_HA_ UNIX-os alkalmazásból akarod használni, _AKKOR_ a szemantikával eleve probléma lesz, és ezt a júzer észreveszi.

_HA_ _NEM_ UNIX-os alkalmazásból akarod használni, _AKKOR_ a szemantikával ugyan nem lesz problémád, de _AKKOR_ nem mindegy, hogy az amúgy is szükséges Samba csinálja meg az ellenőrzést, vagy a kernel?

Erre gondolsz?
http://www.compu-art.de/mars_nwe/

Már több mint egy évtizede nem fejlesztik. Egyáltalán működik még a mostani Linuxokon?

1 évtizede? Már 15 éve se fejlesztették, én anno használtam. Voltak vele alapvető szopások (bizonyos hibaágakat nem kezeltek le így, így a worst-case hibamegoldás network timeout esetén a reboot volt), illetve igazából az NW3.x tudását sem implementáltak csak kisebb részben, szóval olyan sok haszna nem volt neki.

32 biten siman mukodik, 64 biten csak akkor, ha a megfelelo helyeken lecsereled a long int-et int-re, mert kulonben a halozati csomagokban nehany 4 byte-os mezo 8 byte-os lesz, es ugy nem igazan fog mukodni ;-)

Akkor a felhasznalok tobbsege el van rontva, es ujra kellene oket tervezni.

A mostani POSIX jogrendszer nem biztosit vedelmet a veletlen torles ellen, a mappaba valo iras lehetosegenek megtartasa mellett (ugye magat a torlest a tartalmazo mappa read-onlyva tetelevel tudod blokkolni, de ezzel blokkolod az uj fajlok letrehozasat is). Meg lehet ugyan a dolgot kerulni, de rettenetesen maceras, es nem is egeszen straightforward.
--
Blog | @hron84
Üzemeltető macik

Idézet:
Akkor a felhasznalok tobbsege el van rontva, es ujra kellene oket tervezni.

Ezzel, látod, erősen egyetértek. :-D

Védelem a _véletlen_ törlés ellen? Hát figyeljen oda, bakker, a unixok sosem arról szóltak, hogy minden hülyét pátyolgatnak.

Ave, Saabi.

Te meg sose rontottal el semmit? Dehogynem. Es boldog voltal/lettel volna, amikor utolag letoltak, hogy miert nem figyeltel oda? Megold az barmit is, netan visszacsinalja az elrontott dolgot? Ugye, hogy nem!

Lehet ilyen hangzatos mondatokat puffogtatni, de ez egyvalamire jo: letolni a felelosseget, semmi masra. Kicsit sem konstruktiv. Nem gepek vagyunk, hanem emberek, ha egy rendszert embereknek tervezel, bele kell szamolnod, hogy az emberek benak es hibaznak, es nem mindig eleg csak ujjal mutogatni a vetkesre, van amikor ennel tobbet kell tenni.

Idézet:
Vége a világnak, vége
a reménynek
Városok pusztulnak,
srapnelek zenélnek.
Emberek vérétől
piros a tarka rét.
Halottak fekszenek az
úton szerteszét.
Még egyszer elmondom
csendben az imámat:
"Uram, az emberek
gyarlók és hibáznak..."

--
Blog | @hron84
Üzemeltető macik

A desktopomon van védelem, Time Machine-nak hívják, serveren meg figyelek. Nagyon. Amúgy a letolás annyit segít a dolgon, hogy _legközelebb_ jobban figyelsz. Amúgy meg a törlés csak egy módja egy file tönkretételének. Mert ha ez ellen védekezel is, mit csinálsz felülírás ellen? Vagy minden lehetséges scenarióra felkészülsz, a géped meg más sem fog csinálni, csak arra figyel, hogy valamit el ne tolj? Köszönöm, ebből én nem kérek, én az emberektől várom el, hogy figyeljenek, gondolkozzanak. Tudom, ez utópia, de a remény hal meg utoljára.

Ave, Saabi.

Huh.

"serveren meg figyelek. Nagyon."
vs
"Amúgy a letolás annyit segít a dolgon, hogy _legközelebb_ jobban figyelsz."

Ha mar igy is nagyon figyelsz, hogy tudsz meg jobban figyelni?

Nem, teljesen felreerted a problemat. Akarmennyire is figyelsz, lehetnek olyan helyzetek, amikor hibazol, akarmiert. Ember vagy, termeszetes, hogy hibazol, ezt bunkent nem rohatja fel neked senki. En is mindig _nagyon_ figyelek, megis becsuszik 1-1 hiba, es azzal nem vagyok beljebb, ha letolnak, mert utana is pont ugyanannyira tudok figyelni, es pont ugyanannyi eselye van, hogy becsusszon valami hiba. Azt, hogy az adott specifikus hibat hogyan lehetne elkerulni, az meg letolas nelkul is rogzul.

Amirol itt szo van, az az, hogy az emberi hiba lehetoseget minimalizaljuk, ez is egyfajta security faktor. Persze, a feluliras ellen nem ved, de az ellen se ved, ha becsap egy meteor a szerverhelysegbe, egyszeruen nem az a feladata, hogy az ellen vedjen. Valamiert csinaljuk a biztonsagi menteseket is, nem?
--
Blog | @hron84
Üzemeltető macik

Ez már filozófia kérdése, mennyire védjük az embereket saját maguktól. Mivel a UNIX pártízéves történelme során nem alakult ki a véletlen törlés elleni védelem, úgy tűnik ez mégsem olyan nagy probléma, mint amilyennek tűnik.

Ave, Saabi.
ps: mondjuk ebben nincs igazam, ahogy arról a .Trash - és hasonló - könyvtárak tanúskodnak. Hát, ez van, aki nem tud figyelni, használjon GUI-t. :-D

+1

Nézd meg a sticky bit fogalmát.
Pont erre lesz jó, csak a létrehozó tudja törölni a fájlt.

+1 sticky bit a szülőmappára és elveszed a juzertől a fájlt, így csak írási jogot kap, törölni nem tudja. Újat létrehozni, mást törölni igen.

Igen, de ezzem meg más baj van. Lásd lentebb, ott kifejtettem, hogy mi.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szerintem ezt Linux egyszerűen nem tudja. Viszont NTFS igen. Indítasz egy Windowst szervert, beállítod a jogokat egy mappában, és Sambával megosztod a Linuxnak :).

Amúgy meg semmi értelme a dolognak, ha írni lehet tetszőlegesen, akkor nem mindegy, hogy létezik-e vagy sem? Úgyis el tudják rontani rosszindulattal vagy véletlenül, ha nem is törölhetik.

--

Ahogy már többen is írták, ez nem kivitelezhető.
És nem, nem filerendszer vagy egyáb hiányosság, az - hogy ilyenre van szükséged - defekt by design.

Hiába lehetne megoldani hogy ne tudd törölni a file-t, ha a tartalmát lehet módosítani, akkor pl szélsőséges esetben maradna egy üres file-od...

Mivel gondolom nem ez a cél, így messzebbről kell újratervezni a megoldást, ahol ez mint probléma előjött.

--
zrubi.hu

+1

Kérdés, hogy mit akarsz rögzíteni? A file tartalmát, vagy a tényt, hogy ott van? Ez utóbbira megoldás lehet egy hardlink egy olyan könyvtárban, amit senki más nem tud módosítani és egy program, ami figyeli, hogy az adott könyvtárbejegyzést törölték-e? Ha igen, újralinkeli.
A file tartalmát viszont nem tudod megőrizni, ha írásjogot kell adnod rá.

Ave, Saabi.

Köszönöm a hozzászólásokat. Mivel sok volt a félreértés, leírom az eredeti problémát, így világossá teszem, miért nem baj, ha 0 hosszúságúra felülírják a file-t, s miért baj, ha azt törlik.

Van két felhasználóm, ezek user1, user2, továbbá ezen két felhasználó default group-ja legyen csop nevű.

Mindkét felhasználónak van egy-egy thunderbird profilja, de van közös mailbox, ezért user2 thunderbird profilja alól a közös mailbox alkönyvtára az egy symlink user1 TB profiljának megfelelő alkönyvtárára.

Az umask 0002 mindkét felhasználó esetében. A baj abból van, hogy a Trash file-t a TB 0600-as joggal hozza létre, nem pedig az umask szerint, ezen felül előfordul, hogy törli, majd létrehozza. Ez baj, mert ha a 2-es felhasználó létrehozza a Trash file-t user2:csop 0600-val, akkor abba user1 nem tud majd írni, így user1 alól nem lehet e-mailt törölni.

Odáig eljutottam, hogy amennyiben a Trash file-t root:csop 0660-nal hozom létre, úgy a file jogait a thunderbird nem módosíthatja, a file-t tudja írni, hiszen :csop-nak van rw joga a Trash-re, s mind user1, mind pedig user2 tagja a csop csoportnak.

Igen ám, de az a gond, hogy a TB letörli a Trash file-t, létrehozza mondjuk user2:csop 0600-zal, és innentől kezdve user1 megszívta.

A sticky bit nekem is eszembe jutott, csak azzal meg az a gond, hogy mondjuk az Inbox user1:csop 0660 jogú, majd user2 alól tömörítünk. Ekkor létrejön egy ideiglenes file user2:csop 0660-nal, majd ezen ideiglenes file-t átnevezné a TB Inbox-ra, de mivel az user1 tulajdonosú, nem fog sikerülni az átnevezés user2 részéről.

ACL-ekkel valahogy meg lehet ezt oldani? A lényeg, hogy a Trash root:csop 0660 ne legyen törölhető.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Az ACL nem változtat azon, hogy jelenleg rwx jogokat ismernek a *X világban, csak finomabban tudod hangolni, hogy kinek r és kinek w.

De ha az immutable nem jó, mit szólsz az append only flag-hez?

Jól hangzik, csak a Trash az olyan, hogy rövidülnie is kell. Amúgy szerintem SELinux-szal megoldható, csak ahhoz meg nem értek, bonyolult, sőt, szerintem nehezen karbantartható.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ha ebbe az irányba nézelődsz, akkor az AppArmor is elég lehet.
Ezzel együtt a lentebb írt megoldás - IMAP szerver - szerintem is célravezetőbb lenne.

Fedoráról van szó, ott SELinux az alapértelmezett. Elvi felvetés volt részemről, nem kívánom magamnak.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én erre azt mondanám, hogy láthatóan a TB nincs felkészítve shared mailbox directory kezelésére, ezért a probléma megoldását máshol keresném.

Ave, Saabi.

Legegyszerűbb lenne megpatchelni a forrást...

--
A főnököm mindig megtartja amit ígér, ha pénzt ígér azt is!

"ACL-ekkel valahogy meg lehet ezt oldani? A lényeg, hogy a Trash root:csop 0660 ne legyen törölhető."
És akkor miért nem elég arra az 1 file-ra felrakni a sticky bit-et?
Egyik user sem tudja törölni mindkettő írhatja...

Ez valami Linux-specifikum, hogy a sticky-bit a fájlon megakadályozza a törlést? Mert könyvtáron már halottam ilyet, de fájlon az egész mást jelent(ett).

No ez felpiszkálta az agyamat, és megnéztem VM-ben. Megnyugodtam, természetesen semmi ilyesmit nem jelent. Kipróbáltam saját, és más tulajdonában levő könyvtárban is, a fájl nem az enyém, de számomra írható a könyvtár - és az rm természetesen hülyeséget kérdez, de törli a sticky-bites fájlt.

bucogi@verctra:/tmp$ ll akarmi
-rwxrwxrwt 1 root root 7 Oct 8 08:16 akarmi*
bucogi@verctra:/tmp$ rm -rf akarmi
rm: cannot remove ‘akarmi’: Operation not permitted
bucogi@verctra:/tmp$ ll akarmi
-rwxrwxrwt 1 root root 7 Oct 8 08:16 akarmi*

Természetesen a /tmp könyvtáron van írási jogom és mégis pont az történik, hogy nem tudom törölni a fájlt
Ubuntu 14.04.2 3.13.0-48-generic kernel.

Természetesen elsiklottál a lényeg felett. Ha valóban a /tmp-ben történik mindez, akkor az nem a fájl sticky bitje miatt van, hanem a /tmp saját sticky bitje miatt.
Úgyhogy N-edszer is hangozzék el:
*X rendszerekben fájl (könyvtár, szimlink, stb) törléshez a fájlbejegyzést tartalmazó könyvtár jogai a döntők, a fájl saját joga NEM. Ha a szülő könyvtárra van W (írás) és X (azaz keresés) jog, akkor a benne levő fájl törölhető. Függetlenül a fájl saját jogától / tulajdonosától / stb. Ez az általános elv tovább bonyolítható a szülő könyvtár sticky-bitjének beállításával, ekkor ugyanis 3 feltétel VALAMELYIKÉNEK teljesülése IS szükséges:
- rendszergazdaként törlök
- enyém a fájl
- enyém a könyvtár.
PONT. FINITO. END. További kákaárusok kedvéért, ez csak abban az esetben érvényes, ha un. POSIX jgosultsági rendszer van érvényben, ha pl. az un. NFSv4ACL bejátszik, no ott már van fájl saját törlését szabályozó jog - de mint ezt ebben a topicban párszor már körbejártuk, a világ legüberfaszább OS-ének kikiáltott Linuxban gyakorlatilag nincs olyan fájlrendszer, ami ezt implementálná. (Ellentétben a lesajnált FreeBSD-vel, ahol mind az UFS, mind a ZFS tud ilyet.)

Azt olvastam, hogy a Linux kernel file-on ignorálja a sticky bitet, csak directory-n értelmezi.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

megoldható. fuse és saját implementáció.

Esetleg fuse és bindfs.

Megnéztem ezt a bindfs-t. Nem, azzal nem lehet.

freebsd/illumos/smartos tetszés szerint + zfs.

https://blogs.oracle.com/marks/entry/zfs_acls

Nekem már megvilágítottad az elmémet, és tudom, hogy FreeBSD alatt UFS-sel is meg tudnám oldani. A lényeg az ACL-ben van - de nem POSIX, hanem NFSv4-e ACL kell ide. Kár, hogy nagytestvér csak egy elég régi találatot dob arra, hogy valaki belepeccselte azt ext3-ba - az össze többi linuxos FS-ről azt látom, hogy nem tudják. Ha véletlenül igen, valaki világítsa meg az elmémet néhány linkkel.

esetelg kipróbálnám, hogy linuxon zfs hogy muzsikál (zfsacl).

Ha az a baj hogy a TB rossz umask-al hozza letre a Trash file-t, akkor vagy azt kell megfixelni, vagy pedig cronjobbal `test -f Trash && chmod g+rw Trash`?

A normal cronjob legfeljebb perces felbontast tud, ami nem feltetlen elegseges. Ide inkabb valami incron kellhet...
--
Blog | @hron84
Üzemeltető macik

Legyenek a mailboxok két teljesen külön mappában, és amit meg akarsz osztani, azt hardlinkkel tedd oda mindkét helyre.

--

Az annyira nem jo, mert pl. egy kompaktalas levalaszthatja valamelyik mailboxot siman, ha a kompaktalas vegen a regi fajl letorlodik, es a tmp fajlt atnevezik. Onnantol kezdve az a fajl egy forkja a shared foldernek, es az eletben tobbe nem frissul.
--
Blog | @hron84
Üzemeltető macik

Mindkét felhasználónak van egy-egy thunderbird profilja, de van közös mailbox, ezért user2 thunderbird profilja alól a közös mailbox alkönyvtára az egy symlink user1 TB profiljának megfelelő alkönyvtárára.

Nem tudom ez a megoldás ötlet hogyan született, de szerintem itt van elrontva a design.

Erre a megoldás: IMAP.

Akár 2 felhasználó miatt is. Főleg, hogy a gyakorlat azt mutatja, hogy az a két felhasználó amire most tervezel valamit, később majd változik, bővül, külön gépet akar majd használni, stb. És akkor már biztosan Te sem gondolkodnál ilyen hack megoldásokban, hanem rég felhúztál volna egy IMAP szervert, és jóidőre megoldottad a most még nem létező problémákat is ;)

Szerintem.

(Persze a feladat/probléma teljes ismerete nélkül ez is csak ilyen beleokoskodás jellegű tipp ;)

--
zrubi.hu

A feladat annyi, hogy TB-ben van több mail cím, de ezek egy része ne látszodjon ugyanezen a gépen másik loginnel belépve, viszont néhány mailcím ugyanúgy használható legyen. POP3, és a helyben tárolt levelek kezelhetősége megmaradjon.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Adott file esetén inotify segítségével sok mindent meg lehet oldani, de szerintem ennek a feladatnak így nincs semmi értelme.

Oldalrol bekiabalva: semmilyen mod nincs arra, hogy POP3 helyett IMAP-ot hasznaljatok? Az a baj, hogy amit meg akarsz valositani, az sajtreszeles barmilyen e-mail klienssel, a problema nem TB specifikus. Egyszeruen ezeket a dolgokat nem erre talaltak ki.
--
Blog | @hron84
Üzemeltető macik

A baj abból van, hogy a Trash file-t a TB 0600-as joggal hozza létre

a) megoldás: át kell írni a TB kódját
b) megoldás: LD_PRELOAD (és akkor csak az ominózus mkdir() hívást kell felülbírálni)
c) megoldás: a közös mailboxra shared IMAP folder (dovecot elvileg tud ilyet)

telepíts helyben imap szervert, fetchmaillel töltsd pop3-ból a leveleket, kézbesítsd a megfelelő helyi imap mappákba a thunderbirdben pedig a helyi szerverre csatlakozz IMAP-pal.

Igen, ez az elegáns és korrekt megoldás.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Nem lenne sokkal egyszerűbb ha felvennéd a másik usert is Thunderbirdbe? Simán kezel több imap accountot, és tisztább megoldás mint ez a haxxorkodás.

Illetve megfontolhatnád egy modern webmail rendszerre történő átállást. Már mindent tudnak amit a natív email kliensek.
Zarafa tud mail mappákra lebontva csak olvasási, írási-olvasási jogot adni bármelyik szerveren levő usernek. Van drag and drop, calender, contacts minden ami kell.

Nekem PGP/GPG *kell*. Nincs normális semelyik webmail-ben sem. Míg egy kicsit is komolyabb lokális klienshez gyakorlatilag mindegyikhez van.

Akkor neked nem a törölhetetlenség az igényed, hanem a jogosultság, erre elég egy inotify alapú monitor és az intézkedik változáskor. Persze 1000+ tömegekre nem optimális, neked jó lett volna, ha nem váltasz

Az incron eddig elkerült engem, de most elkezdek barátkozni vele, köszönöm az ötletet.

Persze 1000+ tömegekre nem optimális, neked jó lett volna, ha nem váltasz

A mbox vs. maildir-re gondolsz? Claws-mail esetén is fennáll a probléma, mégpedig a .claws_cache és .claws_mark file-ok esetében, de magukkal a levelekkel nincs ilyen baj, tehát mindössze néhány file igényel beavatkozást.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Én az extended attribute irányából kezdtem keresgélni - azt látom, hogy meg lehet vele oldani, de kétlem, hogy van rá kész megoldás.

Miután felraktam a hiányzó attr csomagot (sudo apt-get attr), és tök fölöslegesen fellapoztam a setfattr / getfattr doksikat, megnéztem a lényeget: man 5 attr (a man 1 attr nem jó :-) ). És feketén-fehéren ott van, hogy a security névtér az pont alkalmas ilyesmire, csak éppen erősen kétlem, hogy a hozzá szükséges kernel security module már készen lenne. De véleményem szerint ennek a funkciónak az implementálása hozzáértő számára ujjgyakorlat szintű.

Azt hiszem, nem kernel modult szeretnék írni, csak egy egyszerűnek tűnő problémát megoldani.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Fentebb már írtak hasonlót, de kicsit konkrétabban: esetleg egy unionfs(-szerű valami)? Nem gondoltam végig, hogy konkrétan használható lenne-e, de kicsit fáradtan nem tűnik halott ötletnek (értsd: egy-két gondolatot talán megér, mielőtt kidobod).

Workaround: barátkozom a Claws Mail-lel.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Csinalj ra egy hardlinket egy masik konyvtarba.

Ezen már gondolkodtam, de nem lesz jó.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

MEGVAN :)

sudo mount -o bind notdeletable notdeletable

Amikor torolned:

rm -rf *
rm: cannot remove ‘notdeletable’: Device or resource busy

:D :D :D

Zseniális! Nagyon szellemes, ötletes, tetszik, marhajó, stb.! :D

Egyébiránt nem olvastam HUP-ot, próbáltam megoldani magam. Workaround lett, kidobtam a Thunderbird-öt, lett helyette Claws-Mail. Ráadásul a Claws-Mailben konfigurálható a chmod. Mélyrehatóbb teszteket nem csináltam, de eddig úgy tűnik, veszi az akadályt.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

HTML mailekkel mennyire boldogul a claws mail?

Bár már megoldottad de így utólag még egy tipp az eredeti problémára, így már csak a hajónapló kedvéért.
Külön partícióba rakod a felhasználónkénti .thunderbird könyvtárakat és onnan linkeled a home-okba. Ezt a partíciót pedig az fstab-ban így mountolod fel:
/dev/sda5 /media/thunderbird ext4 rw,user,exec,umask=000 0 0

Egész tűrhetően. Van Dillo-n alapuló HTML-nézője :-), meg webkites és libgtk2html alapú is.

Van egy Fancy nevű plugin-je:

This plugin renders HTML mail using the WebKit 2.4.9 library.

A külön partíciós filerendszeres megoldásod nem világos. A cél az volt, hogy az alkönyvtár minden file-ja törölhető, írható, olvasható legyen a csoport tagjai számára, viszont a Trash file-t ne kehessen törölni, csak írni és olvasni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ez másként közelíti meg a problémát. Ha a TB fájljai olyan partícióra vannak irányítva ahol minden fájl mindenki által írható (mount opció alapján) akkor nem baj ha az egyik felhasználó törli a fájlt majd saját uid-dal létrehozza újra, mert úgyis írható marad a másik user számára is.

Jé, tényleg! :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Ennyire nem vágom az ext4 sajátosságait, de ha a júzer a saját umask-ját átállítja az nem rontja el?

Az login-kor aktuális user umask-ot felülbírálja az fstab-ban külön definiált umask. De ha menet közben változtat a user az umask-on az már okozhat gondot. A leírt probléma alapján itt ez nem fenyeget mert nem több száz proginfós egyetemista által nyúzott unix szerverről van szó, hanem valami irodai gépről ami két usert szolgál ki.
Nagyobb probléma maga a Thunderbird. Ha az akarja forceolni az umasktól eltérő jogokat. Ezt ki kellene próbálni, hogy felülbírálható-e a mount-hoz fstab-ban megadott umask.

Természetesen biztosan működő megoldás, ha olyan fájlrendszert rakunk erre a partícióra amin egyáltalán nincsenek jogok, például fat32-t. Ott garantáltan felülbírálhatatlan az fstab-ban megadott umask. De ez nem túl elegáns megoldás és valószínűleg felesleges is.

ACL-lel bebiztosítható az others általi írásjog. Fstab-ba:
/dev/sda5 /media/thunderbird ext4 rw,user,exec,umask=000,acl 0 0

Ha még nem lenne kell az acl csomag (apt-get install acl)
Majd:
setfacl -d -m o:rw /media/thunderbird

Nem akarlak elkeseríteni, de ezt tuti nem próbáltad ki. Mert az ext4 nem ismeri az umask paramétert...

Továbbá azt a szemantikát, amit elképzeltél, megvalósítani sem igazán lehetne. Az aktuális user umask-járól ugyanis nem lehet eldönteni, hogy azon a user menet közben változtatott (és aztán később beállította ugyanarra, mint ami az induló érték volt), vagy sem.

Jó régen használtam utoljára umask-ot még ext3-mal, azzal működött.
Az acl viszont biztosan működik így ext4 fájlrendszerrel is.

Nagyon régen lehetett, mert mostanában nem volt ilyen flag az ext3-nál se.
Sőt, a privát véleményem, hogy rendes jogosultsági rendszerrel ellátott fájlrendszereknél még sosem láttam ilyen flageket (umask, uid, gid, stb.), csak a fat/ntfs/haverjaik esetében.

Az acl hiába működik, nem tudja felülbírálni azt, ha a program maga dönt úgy létrehozáskor, hogy a max. jogokhoz képest eleve csökkentett jogokkal kívánja a fájlt vagy könyvtárat létrehozni (ez az umasktól totál független dolog). Ilyenkor a kifilterezett jogosultságbiteket az acl maskban is ki fogja kapcsolni, és máris nem öröklődnek a beállított jogosultságok.

Akkor marad vfat vagy ntfs fájlrendszer ennél a megoldásnál.

" acl maskban is ki fogja kapcsolni"

Ennel szomorubb a dolog: a torles+letrehozas ures ACL tablat eredmenyez.
--
Blog | @hron84
Üzemeltető macik

zseniális megoldás :)

A nyakam ra, hogy ezen meg akik a kernelt reszelgetik is felkapnak a fejuk :D

--

"You can hide a semi truck in 300 lines of code"

Ez nem hiba amit javítani kellene.

Nem is arra celoztam, hanem a tipikus "nem egeszen erre lett kitalalva" pillanatokra.

--

"You can hide a semi truck in 300 lines of code"

++ ... nagyon tetszik ... ez olyan igazi linuxos +oldás ...
//ejtőernyő heveder csat ugyan, de kiválóan lehet vele sört nyitni, merhát életmentő eszköz// :):):)
_____________________
www.pingvinpasztor.hu

Csak ne akard röptében növelni alatta az lvm-en lévő fájlrendszert, kivéve, ha a mind mount-ot leszeded az átméretezés előtt.

Miert mit okoz ? Meg sose probaltam atmeretezni olyan particiot amin bind mountoltam valamit... Lehet itt az ido :)

Meg lennék lepve, ha bármit befolyásolna...

Emlékeim szerint RHEL5-ön sikerült adatvesztést produkálni erősen használt, bind mount-okon (eredeti+két bind mount) keresztül is elért ext3-on. De majd utánanézek, mi is volt pontosan.

Ezért hálás lennék, mert hasonló (Debian, de a többi stimmel) környezetem van, ahol még nem kellett növelnem at fs-t, de ha kell és emiatt kisiklik a vonat, akkor jobb ha előre tudom :D

puding próbája az evés imho :)

Carpe diem! :D

Na, azt tipikusan nem az ilyen scenariokban szeressük :)

#yolo ? :)

Nekem mondjuk a gép (tb) meg a teló simán kezeli ugyanazt az imap fiókot. Ez nem megoldás? Mármint, hogy közös imap fiók?

Mondom, POP3! :) Lokálisan tárolom a leveleket.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Tárold lokálisan IMAP szerverben a leveket :D