fájl tulajdonos szerepe

Linux-kezdő

Sziasztok!

Az lenne a kérdésem hogy ha létrehozunk egy fájlt linux alatt, akkor mi értelme van annak hogy ez felhasználóhoz tartozik?

Ezt csak tájékoztató jellegű hogy kihez tartozik a fájl?

Chown paracssal át adhatjuk másik felhasználónak is, de ennek is mi értelme van?

 

HA mondjuk Csabához tartozik mint tulajdonoshoz a fájl és futtatható, akkor ha Olgi lép be akkor ő nem tudja futtatni a fájlt?

  • 1168 megtekintés

( mauzi v | 2022. 10. 02., v – 12:12 )

Szerkesztve: 2022. 10. 02., v – 12:16

Manapság a dolgok tulajdonjogának egyre inkább csak tájékoztató jellege van, a fájlokat is előbb-utóbb államosítják és újraosztják őket a Webkiszolgáló TSZ és az Adatbázisszerver TSZ között! :)
(Bocs, ez egy rejtett subscribe)

( buccaneers v | 2022. 10. 02., v – 12:16 )

pl, ha többen használnak egy linux szervert és én is ott tartom a pornó gyűjteményemet és nem akarom, hogy a többiek is lássák mi van a mappámban.. - erre jó a file-ok/mappák jogosultsága

Istennel a hazáért és a szabadságért !

( beatnull | 2022. 10. 02., v – 12:17 )

Maga a kérdés valóban messzire vezet de a jogosultság-rendszer nem egészen Linuxos dolog, NTFS fájlrendszeren is van ownership.

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

( locsemege v | 2022. 10. 02., v – 12:29 )

Az az értelme, hogy a tulajdonosnak más jogai lehetnek egy file-ra, mint a csoportnak, és megint csak más jogai vannak mindenki másnak. Ne tévesszen meg, hogy alapértelmezetten például -rw-r--r--, tehát 0644 jogok miatt mindenki olvashatja a file-t, mert ez nincs szükségképpen így. Lehetne nyugodtan -rw-------, azaz 0600-as jog, és akkor csak a tulajdonosa olvashatja, írhatja. Viszont a törölhetősége attól függ, a file-t tartalmazó alkönyvtárra van-e írási jogod. Illetve még annyi, a root-nak mindenre van joga.

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

( uid_6201 v | 2022. 10. 02., v – 13:18 )

3.4-es fejezetet alaposan olvasd el: https://docs.freebsd.org/en/books/handbook/basics/#permissions

Egy trükk, hogy lásd az ősrégi időkből származó filozófiát, amikor még tömegével jelentkeztek be a szerverre, hogy ott futtassák a programokat, de csak amihez jogosultságuk volt:
   - tied a bináris fájl, futtatási jog rajta a csoportnak és/vagy csoporton kívülinek is megadod a futtatás jogát.
   - suid bitet bekapcsolod a fájlon
Mi történik, ha a egy másik user elindítja ezt a programot, kinek a nevében fut a szoftver és a szoftverben korlátozott módon kinek a fájljait tudja olvasni/írni/törölni?

Chown paracssal át adhatjuk másik felhasználónak is, de ennek is mi értelme van?

User nem tudja chown-nal áttenni másik user nevére a fájlt, ezt csak a root tudja megtenni. Hozzá pedig ilyenért nem fordulunk. Lásd: Pokoli operátor naplója.

Ezek ma, amikor a legtöbbünk számára létezik a grafikus konzol, az egyetlen bejelentkezett user meg a sudo és ennyi, akkor leginkább a feledés homályába merülnek. Amikor még volt az egyetlen nagyszerver és azon lógott akár több ezer (!) különféle csoportosulás (RS232 kábelre kötött terminálok sora a hosszú folyósón, később hozzájött a TCP/IP-s telnet/rlogin/rsh majd ez utóbbiakat leváltotta az SSH). A jogosultságot programfuttatás és adathozzáférés szinten egyaránt el kellett tudni választani, erre voltak kitenyésztve ezek.

Még egy érdekesség: nézd meg hogyan van megoldva az, hogy a /tmp -ben létrehozott fájlt csak az tudja törölni, akinek nek a nevén van. Ezt a bitet szintén bármely mappára rá tudod tenni.

off

Fáj a fájl, fájós fajitas, fájásrenyheség. Fájdalomenyhítő fájvirág, fájó fájlattribútum.

on

fajitas: idézet innen:

 

"A hozzáférési jogosultságok kezelése, mivel az inode rekordban törtnik, biztosítja azt is, hogy egy állomány hozzáférési jogait csak a tulajdonos tudja állítani, még abban az esetben is, ha maga az állomány mások számára is írható.

Tulajdonos- és csoportváltás: chown, chgrp

Lehetőségünk van arra, hogy az általunk birtokolt állomány tulajdonosát és csoportját megváltoztassuk. Ez a chown, illetve a chgrp paranccsal történik.

 

$ chgrp staff file1

$ ls -l file1

-rw-r-xr-x 1 demo staff 18 Aug 23 20:42 file1

$ chown janos file1

$ ls -l file1

-rw-r-xr-x 1 janos staff 18 Aug 23 20:42 file1

$

E két parancs használatakor egyet ne felejtsünk: ha egy állomány tulajdonosi jogait átadtuk, akkor a továbbiakban azt mi nem vehetjük vissza, csak az új tulajdonos dönthet így.

Másodlagos csoportok

A UNIX újabb verziói lehetőséget biztosítanak arra is, hogy egy felhasználó több csoportba is tartozhasson. E másodlagos csoportokat a rendszergazdának kell beírnia a megfelelő konfigurációs fájlba (/etc/group). Amikor csoportot szeretnénk váltani, a newgrp newgroupname parancsot kell kiadnunk. Ha newgroupname számunkra engedélyezett csoport, akkor a következő newgrp parancs kiadásáig az új csoportban leszünk, az annak megfelelő hozzáférési jogokkal, s az újonnan létrehozott fájljaink is ebbe a csoportba fognak tartozni. A paraméter nélkül kiadott newgrp parancs visszahelyez minket az elsődleges csoportunkba.

A másodlagos csoportok a csoportmunkák támogatásánál előnyösek. Így lehetőség nyílik arra, hogy valaki elsődlegesen a saját csoportjába tartozzék, de minden egyes projekt, amelyben résztvesz, külön másodlagos csoportként szerepeljen, s az e projekthez tartozó fájlokhoz csak az e másodlagos csoporthoz tartozók férjenek hozzá.

"

Sakk-matt,
KaTT :)

Visszatértem! A hozzászólásom alatt lévő szavazat gomb nem nyomódik meg magától!

Így van, unixos örökség. Az értelme pedig az, hogy egy újabb jogosultsági szint, aminek a mentén jogokat lehet szabályozni. Általában a fájlt létrehozó felhasználónak, mint tulajdonosnak mindenhez van joga, ami a fájllal kapcsolatos (kivéve futtatás, azt be kell állítani). A csoportnak, amiben a felhasználó van, meg a csoporton kívülieknek meg ahogy beállítják, amennyi jogot hagynak. A rootnak meg mindenhez van hozzáférése, engedélyektől függetlenül (bár a futtathatóság neki sem automatikus, de megadhatja magának). Ha a kollégát ez zavarja, akkor adhat szélesebb jogokat a csoportnak is, így a példájában Olgi is hozzá fog férni mindenhez (ha be van állítva a csoportnak a futtatás, akkor futtatni is tudja), ha Csaba csoportjához hozzá van adva. Esetleg lehet jogot adni mindenkinek, de az meg biztonságilag nem a legjobb húzás, kicsit windows-os szemléletű, normi megoldás, ennek ellenére sokan szeretik, mert nem kell utána tovább foglalkozni a kérdéssel. Néhány kezdő szokta azt is csinálni, hogy mindennek 777 (rwx+ugo) jogot ad a 666 helyett, de ez nem a legjobb megoldás, mivel ha minden fájl futtatható, akkor az néhány szoftvernek, főleg fájlkezelőknek félrevezető, megpróbálják a fájlt akkor is futtatni, ha nem bináris/script, ahelyett, hogy mime vagy kiterjesztés alapján a hozzá tartozó alkalmazásban nyitnák meg.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Nem is állítom, hogy nincs, de a kollégának az alap ugo+rwx is sok, azért indította a témát. Én meg azt mondom, hogy nem sok, mert adott esetben ki tudja kerülni a szinteket, egyet beállítani, és azt használni minden userrel. Nem egy akkora szám. Inkább legyen valamiből több lehetőség, és ne legyen kihasználva, mint hogy az egész OS limitált legyen, és egy klikkes userekre tervezve kényelemből megszüntessen beállítási lehetőségeket.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Off: például autodidakta PHP-programozók bármilyen jogosultsági probléma megoldásához úgy kezdenek hozzá, hogy chmod 0777, aztán ha nem segít, akkor majd megnézzük, hogy ténylegesen mi is a baj. (Tipikusan az, hogy a PHP-scriptet a `www` user futtatja, de a könyvtárakat a `teve` user hozta létre.)

( BehringerZoltan | 2022. 10. 03., h – 15:56 )

hm ...van olyan fájlrendszer linuxon ami mentesíthető a jogosultsági proceduráktól mondjuk a fat32 -n kívül - ami ugye kakukktojás? Tehát a jogosultság ellenőrzéséhez szükséges időt akarnám megspórolni. Zongora hangminták, nagyon sok ezer wav. kb 30-40 GB összesen és ultragyors elérés kell. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

látatlanban mondom, hogy rossz irányba kapisgálsz, pár ezer file statolása az semmise. Pl:

~# time find /usr|wc -l
380357

________________________________________________________
Executed in  767.80 millis    fish           external
   usr time  284.36 millis  346.00 micros  284.01 millis
   sys time  498.76 millis  270.00 micros  498.49 millis

és ez végignyálaza azt a 380k filet. Jó, kicsit csalok, elsőre kb 2.5 sec volt, ami egyben azt is mutatja, hogy normál esetben az ilyesmit úgyis be fogja neked valaki valahol cachelni, szóval hamar 1-2 memória műveletté válik. Az is esélyesnek tűnik, hogy egy hangmintha wavot beolvasni nagyságrendileg lasabb lesz, mint megnézni, hogy elérheted-e. Ultragyorsan elérni dolgokat a memóriából kell :)

Nálam ez 174k fájlra 1795 ms először, másodszor futtatva 105 ms. NVMe PCIe 3.0 x2 sebességet tudó SSD, nem a leggyorsabb fajta. ramdrive/tmpfs esetén kicsit gyorsabb lenne, ilyenkor általában nem a jogosultságok, napló, elérési/módosítási időbélyegzők a keresztmetszet, hanem az I/O.

A másik, hogy a kolléga felhasználásánál nem értem, hogy sima hangmintákat, hangszermintákat minek kellene annyira gyorsan elérni. Én egy olyan zenei alkalmazásról sem tudok, teljesen mindegy, hogy lejátszás, vagy DAW/editálás, ahol ez fontos lenne. Minden alkalmazás úgyis előtölti a memóriába, amikkel dolgozik, onnantól úgyse lehet tovább gyorsítani, hacsak az ember a gépet nem upgrade-eli hardveresen.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

A jogosultság ellenőrzés prociidő. Tök felesleges nekem ez az ellenőrzés, nem akarom h erre menjen el az idő - mégha ez az idő nagyon pici is egy-egy esetben. Oké előtölti a memóriába, de amikor használni kell akkor ismét a diszkhez fog nyúlni h maradékot felnyalja, és akkor megint ott a totál felesleges jogosultság ellenőrzés. Minek? 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Szerintem a file hosszát se ellenőrizzük, szerencsés esetben nem írunk túl rajta. Meg az se baj, ha olyan memóriacímre írunk, ahol már nincs is memória. Hülyeség ezeket ellenőrizni, ez mind CPU idő.

Esetleg a feladatra alkalmas számítógép beszerzésén gondolkodtál?

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

Én meg arra utalok, hogy elvileg ugyan igaz, amit írsz, de tudod azt, hogy milyen a vfat implementáció? Össze tudod hasonlítani, hogy az ext4, btrfs, f2fs közül melyik milyen gyors? Ha valamelyik nem ellenőrizne jogosultságot, lehet, még úgy is lassabb lenne valamelyik másiknál, amelyik meg igen. A körülményektől függően lehet, hogy bizonyos esetben az egyik, más esetben a másik gyorsabb.

Ha egy gép futásidejében ez ekkora gond, akkor az a gép alul van méretezve. Vegyél szerver alaplapot, tegyél több processzort az alaplapba, ahol egy processzor is sok magos, egy mag is több szálon végez végrehajtást, legyen sok cache-ed, legyen néhány száz GiB RAM-od. Ha kell a teljesítmény, vedd meg. Az nem megy, hogy egy számító központot akarsz üzemeltetni egy Raspberry Pi-ről.

Tudom, sarkítottam, de remélem, érthető, mire akarok kilyukadni. Van a feladat, ahhoz méretezünk rendszert, nem pedig van a feladat, s összesöpörjük az ócskavasat a sufniban, aztán kesergünk, hogy valójában alkalmatlan a probléma leküzdésére.

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

OKé, de probléma marad. Van egy erősebb gép akkor, de ugyan úgy szükségtelen a jogosultságkezelés. Különösebb fogalmam nincs a fájlrendszerek implementációiról, de gondolom a jogosultság kezelés kikapcsolása egy adott fájlrendszeren csak gyorsítana! 

Bár nekem ennél merészebb elgondolásom volt: 5 gépes rendszer összeállítása, de a rezsikommandó meghátrálásra késztetett! De durván túl lett volna vele tolva a dolog, meg nem is tudom h fért volna el.

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

A "Különösebb fogalmam nincs a fájlrendszerek implementációiról"-ból következik a hibás gondolat, hogy a "jogosultság kezelés kikapcsolása" létező opció. A "gyorsítana" fogalma is érdekes kérdés - ugye ezen az egész dolgon az után gondolkodtál el, hogy az adott fájlrendszert noatime opcióval csatoltad?

Jó, de egy hangszerminta pár mega, meg hányat is kell betölteni általában? Utoljára ez, hogy egy kis metaadatot a fájlrendszerből tölteni, akkor okozott gondot, mikor 486-osokat használtak. A mai procik meg milliószor gyorsabbak, még elvileg a legfosabb N-es Celeron, meg ultralow voltage mobilproci is, ez már sehol nem tétel, hogy ilyen apróságokat nézni, még egy 16 éves Pentium D-s és Core2Duo-s múzeumi csotrogányon se. Igazából az nagyobb terhelés a rendszernek, mikor az egeret, ablakokat mozgatod, meg a hálózatot, netet éred el. Manapság már milliós nagyságrendű kódot futnak egy gépen, most ez a pár sor, hogy jogosultságokat is nézni, ez már elveszik, mint csepp a tengerben.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

kb 10-20.000 zongora hangminta.  Sok mindentől függ: dinamika layerek számától külön a lenyomás, külön a felengedés,  mikrofonok számától, pedálállástól, fedél helyzetétől stb.  30 GB simán összejön. 

Tehát min 64 GB RAM kéne h fel tudja nyalni az egészet. A gépem ami erre a célra van kizárólag használva 16 GB RAM-ot tud kezelni. 

Valójában persze a gyenge procin is elfut, csak hát más beállításokkal. Mondjuk kevesebb polifóniával, lebutított hangmintákkal stb. De nem állítottam sehol, h kritikus kérdés jogosultság ellenörzésére fordított CPU idő! Mások tesznek úgy, mintha ez ilyen formán vetődött volna fel részemről - ami nem igaz!  Nem kritikus, hanem felesleges - én ezt írtam. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Miért a jogosultságokra gyógyultál rá? A SELinux támogatás kell? Hardlinkek, symlinkek kezelését tudja? Sparse file-okat tudjon kezelni? Online tömörítést tudhat?

Nagyon sok feature-t tudhat egy filerendszer. Ezek közül rámutattál egyre, hogy akkor most ez CPU időbe fog fájni, és nem kell. Miért épp ez okoz fájdalmat? Miért épp a jogosultságok?

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

Nem kell betölteni egyszerre az összes hangmintát. Pont azért, mert ritka a 64 GB RAM, meg a futás során előnyöd sem lenne, hogy minden előre van töltve. Hiszen egyszerre úgyse engedsz fel minden pedált, használsz minden mintát, egyszerűen életszerűtlen. Amiket meg használsz, rendszeresen, azokat a Linux kernel cache-eli mint az állat, feltéve, hogy nem spóroltad ki a gépből a RAM-ot, utóbbi esetben meg megint nem a jogosultságok lesznek a szűk keresztmetszet, hanem minden más feladat is, rendszeres kirándulásokat fogsz tartani az óriási Swap-hegyekben.

Maga ez a jogosultságkezelés tényleg elveszik. A fájlrendszer már így is néz egy csomó más dolgot, pl. mappák, hierarchia, fájlméret, naplók, stb., ehhez képest egy jogosultsági flag ellenőrzése elenyésző, 1 ezrelék alatti arány még a metaadatok kezelése között is. Meg azt is figyelmen kívül hagyod, hogy már rég nem a proci a szűk keresztmetszet, hanem minden más, főleg I/O. A proci az idő nagy részében unatkozik (hacsak nem hajtod hosszú fordításokkal, 3D renderrel, meg nem futtatsz egyszerre sok ilyen feladatot, stb.), ha más nem, csak néhány mag. I/O-n meg nem csak a lemez I/O-t értek, hanem mindent, memória, egyéb eszközök bufferei, stb., az esetek többségében ezekre várakozik a CPU úgy is, és az, hogy közben üresjárat alatt ellenőriz neked pár bájtnyi flag-et, az már semmit sem határoz meg, még egy alacsony frekis Atom procinál, meg beágyazott eszközöknél, SBC-knél sem. Ha továbbra sem 486-os procin csinálod mindezt, engedd el a témát, mert egyszerűen csak nem látod jól. Egyszerűen nem ez a szűk keresztmetszet, ha a valódi okot akarod megtalálni, hogy egy adott gépen egy adott alkalmazás nem fut kielégítően, akkor teljesen máshol kell keresned az okot.

Egy nagyon speciális esetet tudok elképzelni, pl. ha egy 5 dollár alatti, 100 MHz-es mikrovezérlőn akarsz futtatni ilyet, bár ez egyrészt nem erre a feladatra való, másrészt meg az ilyen eszközöknél már úgyse szoktak komplett OS-t futtatni, hanem írnak hozzá bináris bare-metal kódot, ha más nem azért, hogy a nagyon szűk, pár MB RAM-ba beleférjenek. Hiszen még ezeknél a prociknál sem maga a prociidő lesz a jogosultságok ellenőrzésére a bottleneck, hanem a jogosultságokat ellenőrző kód mérete, RAM-igénye a többi kóddal összeadva. Ilyen extrém spórolásnál talán van értelme valamilyen szinten ezzel vergődni, minden más esetben én elengedném.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Köszi! Nincs annyi memoriám ami elég lenne! Az indulásnál betölti a wavok elejét a memóriába linuxsampler (ez ilyen hanglejátszó), és a többit akkor tölti be, amikor ténylegesen használatra kerül - miközben az elejét elkezdi lejátszani. Ez elég jól ki van egyensúlyozva már. Inkább a proci időn kéne faragni. Szal ha mindig csekkolgatja hogy akkor ki a tulaj, ki a gorup, user groupban van stb. akkor azon még minimálisan lehetne spórolni talán. Valójában itt nekem totál felesleges a jogosultság kezelés. Lehetne mount opció, h azt hanyagolja. Vagy eleve a fájlrendszer lehetne mentes tőle! 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

"a fájlrendszer lehetne mentes tőle" vfat/fat ilyen - igaz, más miatt nem lesz gyorsabb, mint jogosultságkezeléssel működő fájlrendszerek.
Az alkalmazásod működése is lényeges - nagyon nem mindegy, hogy megnyitja a fájlt, olvas belőle, lezárja, majd az újabb adatokhoz újra open/seek/read/close jön? Mert ebben az esetben nem a jogosultságellenőrzés lesz a "drága", hanem az open/close. Értelmes app az olyan fájlt, amiből többször kell részeket olvasni, megnyitja, olvas belőle, nyitva tartja, és ha újabb részt kell betölteni, akkor már csak az adott FD-t kell olvasni.

Az ext4 elég gyors szerintem, de lehet hogy van ami picit gyorsabb.
Ami elrontunk, ha egy mappába sokezer fájlt dobunk.
Helyette az adattárban például 256 mappa, azok mindegyikén belül 256 mappa, azokon belül már 100...1000 fájl. Így lehet gyors eléréssel 30 millió fájlt kezelni.

ajaj - de jó lett volna, ha ezt elmondod az ANYK fejlesztőinek :-) 

Bevallás mappába - több 10ezer file - mert ott 5 adó év minden cég minden beküldése és még olyan opció sincs, hogy évente külön mappában tudná kezelni...

valakinek ötlete ?

Istennel a hazáért és a szabadságért !

Ötletem nincs, csak egy tizenéve működő rendszerem, amely már 35 M fájlt is kezelt*. Senki sem fogta még fel, hogy miért nem kell hozzá ssd. ;)

Tapasztalatom szerin a feljebb leírt NxNxM elven megvalósított tárolás jól hangzik, de adott méret felett roppant veszteséges tud lenni.

*A "kezel" túlzás. Több féle adattípusra optimalizált inkrementális vagy megőrzési idővel rendelkező mentésekről van szó. A bevallás pont ilyen statikus adatnak feleltethető meg.

Csak arra is tessék gondolni, amit korábban írtam: ha n-elemű útvonalon van a fájl, akkor az eléréséhez n elemen le kell futnia a jogosultságok ellenőrzésének, mielőtt a fájl jogait vizsgálná a rendszer... Szóval ha a /foo/valami001.wav ... /foo/valami999...999.wav fájlok vannak, akkor felolvassa a / könyvtárfájlt, megnézi, hogy van-e benne foo, ha van, akkor a  /foo jogosultságát vizsgálja, ha elérheti az adott user, akkor megnyitja, felolvassa, megnézi, hogy benne van-e adott nevű fájl, majd megvizsgálja, hogy jogosult-e az adott user...
ha lerakod 2-3-n szintű struktúrába, akkor 2-3-n-szer fog könyvtárat felolvasni, keresni, jogosultságot ellenőrizni benne...

Ha tippelnem kellene, az leginkább naiv LIST implementáció lesz valamelyik oldalon, valaki összevárja az egész listát, és hát a dróton is át kell küldeni. (Már ha egyébként a protokoll lehetővé teszi a nem szart, szerintem ott nincs lehetőség kvázi streamelni)

Illetve ha ez is benne van, nem elsősorban a jogosultság fog ott fájni, hanem az egész stat, meg a noatime hiánya.

noatime mellé a nodiratime is dukál. Meg persze ezer dolgot lehet tuningolni a jogokon kívül, pl. hogy mennyi idő után írja le a kernel az írásra memcache-ben álldogáló dolgokat (dirty ratio, sb.), vagy a journal barriert, meg volt régen pl. hash trees könyvtár indexelés, bár azt hiszem az ext4-nél ez már nem nagy divat. Vagy ott az io ütemező kérdése is. Ha egy célra használod a dolgot, a noop lehet a leggyorsabb. Btw. azt írtad a technológia nem teszi lehetővé, hogy megspórold a jogosultság/tulajdonos ellenőrzést, dehogynem! Megkeresed a kernelben ezt a részt, és szépen kikommenteled a forrásban. Persze azért az execution ellenőrzését meghagynám szerintem azt sok toolkit nézi - vagy a kikommentelt ellenőrzésekhez beírod hogy mindenre 777-et adjon vissza, és kész (mondjuk eleve egy jól fordított kernel kapásból gyorsabb a gyárinál). Ja, az acl-eket pl. a noacl mount opcióval ki tudod kapcsolni...

 noatime mellé a nodiratime is dukál

       noatime
           Do not update inode access times on this filesystem (e.g. for
           faster access on the news spool to speed up news servers). This
           works for all inode types (directories too), so it implies
           nodiratime.

Tehát nem kell mellé, a noatime részhalmaza a nodiratime.

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

Valóban, bocs, régen olvastam a man lapját, akkor még ez volt benne, most előtaláltam:

  noatime
              Do not update inode access times on this filesystem  (e.g.,  for
              faster access on the news spool to speed up news servers).

   auto   Can be mounted with the -a option.
...

util-linux                         July 2014                          MOUNT(8)

Persze ez a legzárójelesebb része volt a hozzászólásomnak, hiszen manapság amúgyis default a relatime, aminek eleve nincs olyan overheadje mint a régi atime-nak, ami most már strictatime...

Hát ugye nem a teljes rencert akarnám átjáróházzá tenni! Szóval ilyen dirty-hack a kernelbe nem igazán szerencsés. Csak a hangminták dedikált diskjén, particióján nincs szükség a jogosultság kezelésére. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Az ext4 moduljába is be lehetne tenni mount opciónak a jogosultságok nélküli viselkedést a kernel moduljába ( vagy lemásolod a modult ext5 néven :D ). De persze csak a topic címe miatt írtam a lehetőségről, valójában ezer és egy optimalizációs megoldás van amikkel szerintem sokkal többet lehet nyerni mint a jogosultságokkal, lásd noacl, io scheduler, journal, kernel memory cache handling, stb.  az ext4-et eleve mint általában jó középmegoldásként szokták emlegetni, fentebb is emlegettek már más fájlrendszereket.

Ha meg a processzor időről beszélünk, akkor mégiscsak kernel fordítás - debug symbolok kihagyása, stb. meg persze a default linuxon futó számodra felesleges szolgáltatások kiírtása, visszafogása, pl. naplózás csökkentése, lightweight ablakkezelő, ha kell egyáltalán grafika, stb.

De ha tényleg komolyan gondolod a dolgot, akkor minek a fájlrendszer? az is csak overhead, pl. symlink támogatás, könyvtárak, stb. írj egy programot ami blokkokat címez egy üres partíción, és a program tartja nyilván ki kivel van, akkor pont annyit tudsz belőle implementálni, amennyire szükséged van, ami elmondásod szerint ugye nem sok.

Mit szeretnél megoldani? mert a "nincs jogosultságkezelésre szükség" az egy beakadt lemez, ami megakadályozza, hogy ésszerűen, a valós problémára keress megoldást. Ahogy látom, te a saját ötletedhez ragaszkodsz, ami a te elképzelésed szerint érdemi mennyiségű processzoridőt spórolna.
Milyen tárolóeszköz? Milyen CPU? Milyen módon hangolt/optimalizált kernel? Az alkalmazás hogyan nyitja/zárja a fájlokat? Nyitva tartja-e azt, amit használt egyszer (beolvasta az elejét), vagy nyitja/zárja? A fájlban hogyan pozícionál? Ezek sokkal fontosabb és relevánsabb dolgok/kérdések, mint az, hogy az open() során a processz kontextus néhány bájtját meg a fájl adatainak néhány bájtját néhány jól irányzott logikai művelettel összehasonlítja az OS, és ha "nem jól állnak" a bitek a processz kontextusában, akkor az open egy szép error-ral tér vissza.
Ja, ha a jogosultság ellenőrzésén akarsz spórolni, akkor célszerű minél keveseb belemből álló útvonalra pakolni a fájljaidat, hiszen az /a/b/c/d/e/f/g/h/i/j.qwe fájl esetén 9 könyvtárra és egy fájlra kell jogosultságot ellenőrizni, a /a/j.qwe esetén meg nem 10, csak két ellenőrzés lesz a fájl megnyitása során... (És persze hozzáférési idő (atime) adminisztrálása sem mindegy, hogy kell/nem kell (ez ugye diszk _írást_ jelent), úgyhogy noatime, vagy még inkább read-only mount az, ami valóban erőforrást spórol...

Miért ragaszkodunk a fájlrendszerhez? Mert rendszerezni akarjuk a fájlokat, kereshetővé tenni.
És miért alakultak ki standard fájlrendszerek a kernelben? Hogy ne a usernek kelljen vele szívnia, félreadminisztrálnia (technikai szinten), ezáltal adatvesztést idézve elő.

Az megint más kérdés, hogy fájlrendszert sok szinten létrehozhatsz, akár
  * saját alkalmazásod direkben kezel egy streaming-eszközt (pl. /dev/sda2),
  * netán kernel által biztosított általad választott fájlrendszerre támaszkodsz
  * netán egy olyan userspace-beli alkalmazásra támaszkodsz, amely ad neked fájlrendszer szolgáltatást és lehetőleg backendként közvetlen streaming eszközt használ

Tehát sok lehetőséged van valójában. És hogy mit használsz, azt az is befolyásolja, hogy
  * mi ad megfelelő adatbiztonságot
  * mivel van kevés szívás
  * milyen egyszerűsítési lehetőségeid vannak? Elég szekvenciálisan haladni, netán egy pointerrel ugrálni? Írás folytonosan megy, vagy van közbenső törlés által felszabadult hely, amit szeretnél használni? Ezer kérdés, amivel a feladatra lehet optimálisabb megoldást találni az univerzális fájlrendszereknél.

Volt olyan még lassú 8 bites mikrovezérlős környezetben, hogy mérési adatokat kellett oly módon flash chipre tárolnom, hogy ne koptassam a celláit. Beágyazott, hosszú élettartamú rendszerbe került ez. Ott például a fájlrendszer abból állt, hogy escape karakter után növekvő szekvenciaszámmal írtam fel adatblokkot és ez a flash véges mérete miatt körkörösen ment. Gyors volt és az összes cellát azonos mértékben koptatta. Feszültség alá helyezéskor volt mondjuk egy pici éledési ideje, mert meg kellett keresni a legnagyobb sorszámú szekvenciát. A sorszámtárolás pedig a tervezett élettartam 10-szeresét meghaladóan volt méretezve. És persze itt is jött a hibatűrés kérdése: mi van, ha a szekvencia írása közben elmegy az áram?
Óvatosan a fájlrendszerekkel, a sajátos "innovációkkal" főleg a hibatűrés, adatbiztonság oldaláról lehet könnyen megszívni.

Valójában semmi eget verő probléma nincsen amit meg kéne oldani. Pusztán csak az zavart, h olyan műveletekre megy el CPU idő, amikre nincs szükségem. És elég érthetetlen h miért nincs egy gyors fájlrendszer linuxra, ami nem kezel jogosultságot!? 

M.2 NVMe PCI-e 3.0 SSD 250 Gb ;Régi I3 proci (4 mag) ebből egyik mag dedikáltan a linuxsampleré (csak egy magon tud futni), egy másik a Carláé; ubuntu low-latency kernel; noatime-al csatlova. A read-only tulképp nem is rossz ötlet! Thx!

A linuxsampler alkalmazás intézi fájlműveleteket. Van fordítási opciója enable-max-streams ami olyan 500 körüli értékre van állítva. Most nincs előttem csak emlékezetből írom. Preloadol egy beállított értéket a wavokból. De h pontosan h dolgozik az nem tudom. 

A könyvtárstruktúra által generált jogosultságellenörzés többlet is logikus! Thx újfent!

Mondjuk az is érdekes lehetne, h milyen sorrendben történik a jogosultság ellenőrzés! Tehát ha nem lehet kiiktatni az ellenőrzést, akkor full jogot mindenre és akkor már az első csekkolásnál szabad utat kaphat. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

> ha nem lehet kiiktatni az ellenőrzést, akkor full jogot mindenre és akkor már az első csekkolásnál szabad utat kaphat.

Ha jól tudom, nem tudsz ilyet csinálni. /x/y esetén van ellenőrzés /-re, /x-re és /x/y-ra is. Az ellenőrzés során minden esetben az az első, hogy az OS lekérdezi, hogy aki a programot futtatja, az megegyezik-e a fájl (  a /, a /x majd végül a /x/y) tulajával. Mert ha igen, akkor a rá vonatkozó jogok döntenek arról, szabad-e csinálnod valamit. Ha a tulaj nem egyezik, akkor csoporttagság és csoporttulajdonos egyezőségét vizsgálja, és ha az se stimmel, akkor jön a maradékelv (other jogai). Illetve ezt bonyolítja, ha van ACL a fájlon. Azaz ha ezt az amúgy nem túl lassú műveletet  tovább akarod gyorsítani, akkor amit csak tudsz (értelemszerűen: a legutolsó könyvtár, és a benne levő fájlok) azok legyenek annak a felhasználónak a tulajdonában, akinek a nevében ez a linuxsampler futni fog.

(Végül: valahol szerepeltek a szimlinkek; csak szólok, szimlinkek használatával nem gyorsítani, hanem csak lassítani lehet ezt a fajta lekérdezést, mert előbb meg kell csinálni mindezeket a szimlinkkel magával, majd pedig egy következő körben a szimlink által hivatkozott másik fájllal IS.)

tl;dr
Egy-két mondatban leírnátok, hogy lehet ellopni egy bitcoin-t?

Valójában semmi eget verő probléma nincsen amit meg kéne oldani. Pusztán csak az zavart, h olyan műveletekre megy el CPU idő, amikre nincs szükségem. És elég érthetetlen h miért nincs egy gyors fájlrendszer linuxra, ami nem kezel jogosultságot!? 

Mert valójában egy a gyakorlatban nem létező problémát próbálsz megoldani. Fejedbe vetted, hogy ezzel lehetne nyerni, a valóságban pedig jó eséllyel nem nagyon, ezek CPU időből a valós programod tekintetében elenyészőt esznek, ha a raktár kezd megtelni, nem a habarcsot szoktuk elkezdeni kapargatni a téglák között, hogy nyerjünk egy kis helyet.

Ha valójában extrém igényeid vannak memória, latency, vagy CPU ügyben (bár io műveletek kapcsán ez elég valószínűtlen igény), azokat nem így kell kezelni, hanem valahogy másképp. Jól kell cachelni, jól kell prefetchelni, ésszel kell nyitvatartani filehandleket, nem fst kell használni adatok tárolására, ilyesmi.

> a valóságban pedig jó eséllyel nem nagyon

Tehát lehet :-D

Én értem h lehet mást is állítgatni a teljesítmény érdekében. De ezeket pont úgy lehetne állítgatni akkor is ha nincs jogosultságkezelés. 

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Ez van, ezért nem véletlen ezeknél a rendszereknél a POSIX szabványra hivatkozás. Ha annyira zavar, létrehozhatsz valami saját fájlformátumot, amiben virtuális fájlrendszerként vagy adatbázisként eltárolod a neked szükséges adatokat, jogosultság nélkül, és abból olvasgatsz. Elég nagy munka, és a kód összességében lassabb is lesz, nagyobb overheaddel, mert nem tudod saját kútfőből annyira optimalizálni a kódod, hogy kisebb overhead legyen, mint az a 30 éve, nem tudom hány profi fejlesztő által szénné optimalizált, rommá cache-elhető kernel/fs-driver kód, amit normál esetben használ mindenki.

Nekem az gyanús, hogy igazából nem az overhead zavar téged, csak nem akarsz a jogosultságokkal foglalkozni, arra írtam azt az eshetőséget, hogy az adatpartíción általános 666-ot engedsz mindenkinek, írni-olvasni, esetleg ha futtatni is kell, azokra a fájlokra a 777-et (vagy a mount parancsnál vagy /etc/fstab-ban adsz meg megfelelő permission vagy mask paramétert), és nem kell vele foglalkoznod. Nem ajánlott, de működik. Kulturáltan erre csoportokat hoznak létre, és abba teszik azokat a felhasználókat, akiknek el kell érniük a szóban forgó fájlokat, mappákat, erre engedélyezik.

“The world runs on Excel spreadsheets.” (Dylan Beattie)

Jó, akkor mondom másképp, hacsak a programod írója nem volt durván braindead, akkor a gyakorlatban mérhetetlen nyeresége lenne ennek CPU időben, ha egyáltalán. Attól, hogy neked beakadt, hogy ez felesleges, és ezért jó lenne kivenni, ettől még nem lesz megcsinálva, hogy ki lehessen kapcsolni. Mert ez az OS ilyen, ezeken a kereteken belül oldunk meg problémákat, mint ahogy más is írta már neked, van még kiscsillió dolog, amire valójában nincs szükséged a szintidhez, aztán mégis ott futnak. Továbbá van egy csomó más megoldás, ha ilyenek nélkül akarsz adattárolni, és valamiért nem jó neked az, hogy ezeket induláskor egyszer megugrod, aztán meg dolgozol a meglevő filehandlekből, amikor már valójában számít a cpu. A cuccod jó eséllyel ezt is csinálja egyébként, ha mindennek besamplezi az elejét. Kinyit, eleje felolvas, fd megtart, ha elkezdené használni, akkor amíg játsza le az elejét, hozzányalja a végét.

De nyugodtan kergess tovább unikornisokat. :)

normal linux file rendszeren nem fogod tudni kikapcsolni a posix file jogosultsagokat.

Erre a legjobb olyan file rendszert hasznalni ami ezt nem tamogatja: exFAT es tarsai.

 

Egyebkent RT kernelt hasznalsz? Kerdem, mivel zenei hatteru a kerdesed.

Support Slackware: https://paypal.me/volkerdi

Nem tudom mi a görcs tárgya. Csinálsz egyetlen brutál nagy fájlt, amiben szép sorban egymás után leteszed a wav-okat.
De mielőtt leraknád, megcsinálod a katalógust és innentől csak pointerművelet.

struct wav {
   char azonosito[MAXHOSSZ];
   size_t kezdete;
   // size_t hossza;  -- ez végülis elhagyható, hiszen a következő kezdetéből tudod, egymás után vannak rakva.
} leiro[MAXDARABSZAM];

Aztán ez mögé jöhet a sok-sok wav.
Itt tényleg nincs jogosultságkezelés meg semmi, hiszen ez az egyetlen brutál nagy fájl folyamatosan nyitva van, csak a fseek() és a fread() megy. Jobb esetben pedig mmap() és simán RAM címzéssel kardozol benne.

Milyen görcs?

>  Csinálsz egyetlen brutál nagy fájlt, amiben szép sorban egymás után leteszed a wav-okat.

Nem szándékozom feltalálni ismét a kereket: a normal wavnak 4 GB a korlátja. Tehát el lehet tárolni sok pici wav mintát egy nagy 4 GB -os wavban és azon belül hivatkozni a minta eljére hosszára. Erre van lehetőség SFZ-n (linuxsampleren) belül. Így egy 40 GB hangminta készlet 10 fájlban eltárolható.  Azokat meg nyitva tarthatja. Viszont ez nem a sztenderd megoldás. Csúnya hátulütői lehetnek. pl rögtön kérdéses a preload-dal mi lesz ilyenkor.  Ilyen megoldást még csak <1GB mérettel láttam, ami elfért a RAM ban.  

"antiegalitarian, antiliberal, antidemocratic, and antipopular"

Pedig ha a boltban maximum 350 km/h tempóra alkalmas kerék (gumiabroncs) van, és te rakétahajtású 800 km/h tempójú járművel akarsz kísérletezni, akkor fel kell találnod ki kell fejlesztened a rossz tapadású és egyéb limitációkkal rendelkező, ám 800 km/h tempóra alkalmas kereket.