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

Linux-kezdő

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.

  • 5697 megtekintés

( Atekka | 2015. 10. 07., sze – 15:26 )

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

( trey | 2015. 10. 07., sze – 15:42 )

chattr +i filename

--
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?

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.

( rts | 2015. 10. 07., sze – 15:51 )

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. ;)

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.

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 :-) )

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.

( hrgy84 | 2015. 10. 07., sze – 15:55 )

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

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.

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.

Nem használok RBAC-ot, tényleg csak kérdezem. Az RSBAC biztos hogy tud örököltetni ("inheritance mask");
https://www.rsbac.org/documentation/rsbac_handbook/security_models/acl
https://www.rsbac.org/documentation/rsbac_handbook/configuration_basics…
https://www.rsbac.org/documentation/rsbac_handbook/architecture_impleme…

Legalul van is egy példa erre ACL modullal:
https://www.rsbac.org/documentation/rsbac_handbook/configuration_basics…

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.

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?

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.

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

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.

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

( Bucogi | 2015. 10. 07., sze – 16:05 )

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

( joco01 v | 2015. 10. 07., sze – 16:14 )

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.

--

( zrubi v | 2015. 10. 07., sze – 16:35 )

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

( saabi v | 2015. 10. 07., sze – 17:10 )

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.

( locsemege v | 2015. 10. 07., sze – 19:21 )

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

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.)

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.

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

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)

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.

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

( Zahy v | 2015. 10. 07., sze – 22:11 )

É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ű.

( uzsolt v | 2015. 10. 07., sze – 22:20 )

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).

( locsemege v | 2015. 10. 08., cs – 01:26 )

Workaround: barátkozom a Claws Mail-lel.

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

( mspike | 2015. 10. 08., cs – 11:10 )

Csinalj ra egy hardlinket egy masik konyvtarba.

( mspike | 2015. 10. 08., cs – 11:13 )

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

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.

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.

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.

( ssikiss | 2015. 10. 08., cs – 21:27 )

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?