Törölhetetlen fájlok? [MEGOLDVA]

Red Hat, Fedora, CentOS

Sziasztok,

Adott egy könyvtár 777 UNIX jogosultsággal, amelyhez a következő ACL-ek tartoznak:

# file: könyvtár_neve
# owner: 777
# group: root
# flags: --t
user::rwx
user:felhasználó:rwx
group::---
group:csoport:rwx
mask::rwx
other::rwx
default:user::rwx
default:user:felhasznalo:rwx
default:group::---
default:group:csoport:rwx
default:mask::rwx
default:other::---

Ebben fájlok vannak, 777 UNIX jogosultsággal és a következő ACL-ekkel:

# file: fájl_neve
# owner: 777
# group: felhasználó
user::rwx
user:x2xr7wi:rwx
group::---
group:csoport:rwx
mask::rwx
other::rwx

"csoportnak" tehát a szülőkönyvtárra RWX jogosultsága van.  
"csoport" tagjaként tudok fájlokat másolni a könyvtárba és meglévő fájlokat módosítani, de nem tudom a meglévő fájlokat törölni (semmivel).
Lock-olva nincsenek a fájlok.

Van ötletetek, hogy miért? 🤷‍♂️

( kedz v | 2025. 01. 28., k – 07:53 )

Szerkesztve: 2025. 01. 28., k – 07:54

Immutable fájl esetleg? (chattr -i filenév -el levehető)

Up: mindenesetre egy lsattr érdekes lehet a fájlon, illetve az FS típusa..

kedz

Azért én kerülném a teljes mappákra, meg struktúrákra megadott 777-et, mint a dögvészt. Érdemes korlátozni 644-re, ami futtatható, az 744 vagy esetleg 766 legyen. A 777-re a legritkább esetben van szükség, általában ha kezdők gányolnak, és felcsatolás után nem tudnak írni valamit, akkor az arra való chown -R helyett (néha mount-oláskor elég ehelyett állítani az umask-ot) begányolják az egészet chmod 777 -R-re, ami szintén működik, de elég katasztrofális, mert sok linuxos tool meg futtatni akarja, ami futtatható, és ilyen doksikat meg nem megnyitja, hanem futtatja.

Sticky bit meg hogy kerül rá, az végkép rejtély, hogy ha nem indokolt, azzal ki szórakozna.

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

Azért ha könyvtárra nem adsz X jogot, azzal tudsz szívatni rendesen, szóval azzal együtt, hogy a 777 számomra is kissé meredek (bár értem az ACL-lel kezelést), a javasolt 644, 744 vagy 766 helyett 755-öt javasolnék esetleg 775-öt.

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

Nyilván könyvtárra kell adni x jogot, különben nem lehet listázni benne. Én így szoktam megjavítani, ha valaki más által összegányolt 777 only adatokat kell helyretenni (pl. retró lemezképeknél, archívumoknál találkozok ilyennel, hogy szétcseszett ACL-ek, meg nagybetűs fájl/mappanevek, amik halálra idegesítenek):
find . -type f -exec chmod 644 {}
find . -type d -exec chmod 755 {}

A 644-et fájlokra értettem, a mappára valóban 755-öt kell adni, vagy 777-et adott esetben, ha mindenkinek írnia is kell. Néha kell fájlra is 777, ha tényleg mindenkinek tudnia kell írni, futtatni is, ami elég ritka, de nagyon speciális felhasználásnál előfordulhat, de fent kell tartani a legindokoltabb, legkivételesebb esetekre. Tényleg csak az legyen futtatható, ami bináris vagy szkript, és csak olyan körben (u/g/o), ami indokolt.

Ezeket a setuid meg sticky bites mókákat is nagyon a minimumon kell tartani, átlag felhasználónak ilyenhez az életben nem kéne nyúlnia. Szerintem a kollégánál is úgy alakult ki ez a komplett struktúra, hogy egyszer valaki egy fájl helyett egész könyvtárra adta ki a sticky jogot, az meg öröklődött az összes későbbi fájlra, almappára.

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

Az, de nem az átlag user gyakorlatában. Azért szoktam ajánlani, hogy aki nem tudja, hogy az micsoda, és tudja, hogy feltétlen nem az kell neki, inkább ne b4×tassa, nem jó ötlet.

Meg egyébként is, ajánlom, hogy mindenki, de főleg kezdők felejtsék el ezt a 777-ezést, 644-ezést, sokan reflexből használják, azt se tudják, hogy miket engedélyeznek vele. Használják inkább az ugo+-rwx formát (vagy egy GUI fájlkezelő párbeszédablakát, ahol táblázatosan elosztva grafikusan is látszik), mert beszédesebb, emberileg követhetőbb, szkriptekben is érthetőbb lesz, hogy mire gondolt a költő. Sokszor szelektívebb is, pl. a chmod +x mindenkinek ad futtatási jogot, a chmod u+x csak a usernek, ami tipikusan elég is az esetek többségében. Meg egy 777 felülcsapja a rw jogokat, míg a +x meghagyja minden fájlnál azt, ami volt. Ez a 777 egy ágyúval verébre módszerű overkill kontárkodás, amit régimódi könyvek, meg ilyen nagyon bölcs indiaiak által összeütött quick tutorial-ok terjesztettek el, és nem akar kihalni.

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

Ez a find már 2004-ben is gyenge megoldásnak számított erre a feladatra, és rtfm járt érte az mlf linux listán :) Állítólag ezek gyorsabbak:
find . -type f -print0 | xargs -0 chmod 666
find . -type d -print0 | xargs -0 chmod 777

De az igazán jó, és mindegyiknél gyorsabb megoldás maga a chmod, hiszen tudja a különbséget fájl és könyvtár között... És a find-os megoldásoknál sokkal kevesebbet is kell gépelni, ha a chmod-ot használja az ember :)

Igen, igazad van. Bár nem úgy, ahogy gondolod. A gond az, hogy nem minden find implementáció támogatja az exec paramétert, illetve a chmod-nak sem minden opciója kezeli a mappákat különbözően. Így sok megoldási mód van. Nem hinném azt viszont, hogy gyorsabb lenne sebességre az egyik megoldás, mint a másik. Talán 1 millió fájlnál lehet kimutatsz egy pár másodpercnyi különbséget.

Plusz amire rá akartam világítani, hogy sokszor már elve a chmod-ot se kéne használni. Bosszant a mai napig, hogy én is találkozok ilyen gányolt ACL-ekkel. Pár napja pl. a reddit unixporn-on az egyik screenshot alatt valaki elkérte a szerző háttérképét, az meg is adta valaki másnak a git tárolóját, ahonnan klónoztam, erre a fájlok fele futtatható joggal beállítva jött, gondolom a jóember egy NTFS-3G-vel fuse-mount-olt NTFS kötetről vette, vagy chmod 777-re járt rá a keze. Érted, csomó .jpg kép, futtatható joggal, azt hittem, hogy székkel hátraesek, az ilyet szívlapáttal verném agyon.

Másik kedvencem, hogy bontom a DOS-os arj archívumból a midi fájlokat, szépen ki is bontja, erre nyitnám meg MuseScore kottaszerkesztővel, erre nem listázza őket. Nézem mi a pék, de hát ott vannak, akkor látom, hogy mind nagybetűs, a szoftver meg normiknak készült, és a .MID fájlokat nem látja, csak a .mid végződésűeket szűri ki bedrótozottan a GUI filepicker-ben. Ekkora baromságot.

Épp ezért ilyen esetekre vannak bekészítve ilyen irányú szkriptjeim, amik javítják rekurzívan adott mappába (megerősítést kér mappanév-hez, hogy nehogy véletlenül olyan mappára legyen futtatva glob, regexp alapján, amire nem kéne) a nagybetűsítést, elcseszett fájlnévkódolást, elqrt ACL-eket. Volt már rá annyiszor szükség, hogy érdemes volt ezeket megírni, nem csak 1-1-szer kellett. Sajnos. Ideális világban ilyennel nem kéne szórakozni.

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

Te mutattad a find exec megoldást, erre azzal jössz, hogy nem minden implementáció támogatja? Linuxon még nem találkoztam olyan chmod-dal, amely ne kezelte volna megfelelően a könyvtárakat, a többi *nix kapcsán majd a többiek elmondják, hogy van-e olyan egyáltalán, amiről te beszélsz (mert azért vannak kétségeim).

Az meg, hogy te mit hiszel a sebesség kapcsán, a legkevésbé sem releváns, és a teljes tájékozatlanságodat mutatja a témában.

Ezek szerint még olyat sem láttál, hogy a find exec megdöglött a túl sok találattól. Az xargs legalább ezt kiküszöböli...

A háttérképekkel kapcsolatban már leírtam egyszer, hogy azt se értem, hogy mire jók. Azt nézegeted? Nekem ablakok töltik be a képernyőt, nem is látszana a háttérkép, akkor meg minek?

Igen, mert én anno így írtam meg magamnak, és betettem ide egy valóban működő példát, azt nem gondoltam, hogy nem lesz itt jóváhagyva. Nem azt írtam, hogy mindenkinek pont így kell csinálja, csak hogy van egy ilyen lehetőség, és ez ebben a formában működik. Nem zárja ki, hogy más formában is működik, nyilván.

A find exec meg még soha nem döglött meg semmilyen találattól. Ha az megdöglik az konkrétan rendszerhiba, vagy valami hibás drive I/O errorokba fullad, vagy a rendszer fut swap-ba, vagy ilyesmi, de akkor bármi ledöglik, az xargs meg bármilyen megoldás. Amilyen ritkán van erre szükségem, amúgy is, mert azért nem 1-1-szer van, de nem is túl sűrű, arra ez a megoldás most még jó nekem, ha majd átváltok BSD-re, vagy valami olyan rendszerre, ami a find -exec kapcsolót nem ismeri, akkor majd átírom. Lustaság csak egy szinten, én sem mindig bolygatom azt, ami működik.

Háttérképről lehet vitatkozni. Valóban, főleg tiling alatt nem sok értelme van, mert úgyse sokáig látom, ablakok hamar betakarják, de én szeretem. Nevezz régimódinak, mikor betölt a dektop, vagy amikor új, üres virtuális asztalra kapcsolok, akkor ad egy kis esztétikai közérzetet, vizuális összhangot, sokat meg nem foglal, főleg, hogy néhány virtuális asztalon kilátszik az ablakok közötti résen is valamennyire, meg feldobja valami a monotonságot, hiszen én nem váltok disztrókat meg asztali környezeteket, ahogy sokan, nincs distrohop, így szeretem néha 1-1 új háttérképpel vagy panel/terminál színtémával, új betűtípussal feldobni a desktopot. Nem is mindig háttérképként oldom meg, van, amikor xsetroot-tal csak egy egységes -solid "#rrggbb" színt teszek ki, de akár egy terminálkimenetet, videót, akármit is ki lehet tenni, bármilyen olyan alkalmazás kimenetét, ami tud a root window-ban futni. Sokat enni nem kér ez már modern hardveren. Én már csak azért is kitennék egy színt, ha más nem, mert anélkül csak egy fekete háttér van, és arról tűnhet úgy, hogy valami hibás a rendszeren, vagy grafikai glitch. Így meg egyfajta mérő/tesztábraként is funkcionál, ahogy régen a tévéadásoknál adtak ilyet. Az üres, fekete képernyő még az én spártai minimalizmusoknak is túl meredek lenne. Egyéni ízlés kérdése, megértem azokat is, akik nem akarnak ilyen hülyeségeket, mint háttérkép, panel, van egy ilyen nézet is.

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

Igen, mint írtam, és az okát is, nevezeten, hogy a chmod-nak nem minden implementációja kezeli a -H, -L paramétereket egyformán. Valószínű GNU chmod-nál gyorsabb lenne használni, de BSD-k, Mac-osen nem ugyanazt jelentik ezek a kapcsolók a chmod-nak, nyugodtan utánanézhetsz. Ha már ennyire tolod, hogy man-t kell olvasni, mert kell is. Nem csak Linux létezik, ezt próbálom is minden szkriptnél figyelembe venni. Nem mindig lehet, de ahol lehet, próbálok univerzálisabb megoldást keresni.

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

De van, ilyen opciója, majdnem minden implementációban, de nem mindig jelentik ugyanazt, ott van a csavar benne. Viszont nem is releváns, mert rájöttem, hogy te az X jogra gondoltál, csak nem bírtad rendesen leírni, ami nem egyenlő a kis x jogkörrel. Ez valóban elegánsabb lehet, de én látok vele két problémát, ami indokolja, hogy nem fogom vele helyettesíteni a find-ot. Egyrészt nem POSIX, bár meg kell hagyni, hogy akármelyik rendszer manját nézem, mindegyik ismeri, legalábbis nem sikerült kivételt találni, vagy csak nem elég erősen néztem. A másik, hogy azokra a fájlokra is végrehajtja (igen, nem csak mappákra, ahogy te hiszed), amiket volt +x jog, amit viszont a jelen példában NEM akarunk, mert 777-es gányolást csinálunk vissza. Rémlik egyébként, hogy ez az X anno előjött, és nem ok nélkül maradtam a find -exec-es megoldásnál. Sőt, van olyan felhasználási köre is a find -exec-nek, ahol még az xargs se játszik elvileg, nem lehet kiváltani.

A másik, ami még ellentmondásnak tűnhet, hogy míg egy részről a szelektív ugo-zást ajánlom, másik részről a beidézett megoldásom egységes 644, 755-tel operál. Valójában nem ellentmondás, mert ha van egy normális mappastruktúra, ami nincs szétgányolva, és tényleg csak pár fájlt, vagy egy fajta jogosultságot kell benne rendbe tenni, módosítani, akkor valóban a chmod ugo-t használom, és akkor mehet a +X is, mert ilyenkor jó eséllyel nem okoz gondot. Amire ez a szkript készült, mikor van egy olyan mappaág, amiben annyira szanaszét vannak már a jogok gányolva, hogy a jó isten se bogozza ki, doksikra felesleges +x jog balra, mindenféle sticky bit jobbra, na, ilyenkor tényleg muszáj nem szelektíven végigcsapatni az egészet, nem éri meg tételesen elemezgetni, hogy mit hagyjunk meg. Ezt is természetesen csak olyan mappára futtatom, ami nem lehet / vagy tényleges rendszermappa, mert szétcseszi a rendszert, ezt ellenőrzi is a szkript az elején, és megerősítést kér, nehogy véletlenül rángott rá a keze valakinek a /.-re a ./ helyett. Csakis user mappában lévő adatokra használom. Ezt a 644-et se muszáj benne tartani, akinek nem tetszik, átírhatja 666-ra vagy ami tényleg kell neki.

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

$ chmod -H
chmod: invalid option -- 'H'
Try 'chmod --help' for more information.

$ chmod -L
chmod: invalid option -- 'L'
Try 'chmod --help' for more information.

Ennyit arról, hogy van ilyen opciója (Debian 12).

azokra a fájlokra is végrehajtja (igen, nem csak mappákra, ahogy te hiszed), amiket volt +x jog, amit viszont a jelen példában NEM akarunk,

A végén csak kénytelen leszek megmutatni, hogyan is kell ezt csinálni, mert még azt fogod hinni, hogy érted a dolgot, és nem lehet egy chmod-dal megcsinálni :) Annyit segítek, hogy le is lehet venni jogot, nem csak hozzáadni...

Értem. Csak nem én hangsúlyoztam eddig, hogy olyan szkripteket írok, amelyek egy csomó különböző rendszeren is futhatnak problémamentesen, mert mindent is figyelembe veszek, hogy hol milyen kapcsolók működnek, meg posix kompatibilis-e, és ki tudja milyen rizsák voltak még... Aztán kiderül, hogy nem is használ bsd-t, de hivatkozik rá, hogy ott nem működne... A mellébeszélés nagyon megy, az értő olvasás (man chmod) annál kevésbe...

Engem érdekel. Olyan szinten, hogy ha van két megoldás, és nem különböznek olyan durván bonyolultságban, sebességben, akkor próbálom azt preferálni, ami univerzálisabb, lehetőleg minél több rendszeren működik. Van, amikor nincs választásom, akkor nyilván nem tudom elkerülni, de igyekszek, ha egy mód van rá. Elvileg az find -exec sincs mindenhol, de a gyakorlatban elég rendszeren jelen van ahhoz, hogy mégse zárjuk ki a használatát.

Nem csak parancsoknál, kapcsolóknál követem, de kerülöm a bashizusokat, GNU specifikus dolgokat, systemd, Wayland, stb. függőségeket. Ha pl. a Linuxszal történne valami, simább legyen valamelyik BSD-re váltás, amire nem állok még kész, de évről-évre egyre közelebb leszek hozzá.

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

Ne etessél már, bonyolultságra, meg sebességre hivatkozol, mikor fogalmad se volt róla, hogy a find exec {} mit csinál, nem hogy a sebességét fel tudtad volna mérni... Univerzálisabb... Milyen rendszerekre írod a szkriptjeidet? Arch linuxot használsz, bsd-re majd váltani akarsz valamikor a jövőben (talán) - ezeket leírtad már. Szóval mire is vonatkozik az a nagy univerzalitás?

Ezt csak te hajtogatod, hogy miről nem volt fogalmam. Igazából már elbuktad, mert közben kiderült szakmai levezetéses úton, hogy a -exec-kel sincs semmi baj, annyi, hogy \+ kell utána, akkor egybefűzi az összes fájlra, és egyben fut le az egész, mintha xargs-zal lenne.

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

Nem, nem fűzi egybe az összes fájlra. Sokkal kevesebb lesz, mint az egyező fájlok száma, de nem - feltétlenül - egy.

-exec command {} +

"This  variant  of the -exec action runs the specified command on the selected files, but the command line is built by appending each selected file name at the end; the total number of invocations of the command will be much less than the number of matched files."

És az xargs sem - feltétlenül - egyetlen chmod parancsot fog futtatni.

Még mindig azt hiszed, hogy két find gyorsabb (és "olcsóbb"), mint egyetlen chmod? Nem is tudom, hogy sírjak vagy nevessek...

Szakmai levezetés... Ahogy Hofi mondta: kacagtam oly annyira :)

find . -exec X '{}' \;

1 db. find processz + n. db. X processz

find . -print0 | xargs -0 X

1 db. find processz + 1 db. xargs processz + n. / kurvasok db. X processz + 1 db pipe kreálás + extra I/O

Az utóbbi forma  2 db. találatnál processzben már azonos, a pipe + I/O a vesztesége; 3 db. találatnál már processzben olcsóbb, és kb pariban vannak a pipe + extra I/O miatt.

Szóval sacc/kb 5-6 találattól (nem kell ahhoz milliós találat) erőforrásban sokkal jobb  az xargs-os verzió.

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

OT

Nekem ez a -r opció (meg az indoka) ismeretlen volt. Ránéztem a FreeBSD-s man-ra, ahol is azt találom, hogy van neki ilyenje - a GNU-féle xargs-sal való kompatibilitás miatt (és semmit nem jelent), FreeBSD-n nincs mindenképpen parancsfuttatás.

Ezek után megnéztem az OpenGroups oldalán a szabványt, és - lehet hogy figyelmetlenül olvasok - semmi nyomát nem találtam annak, hogy mit kéne csinálni üres input esetén. Mondjuk -r opciója sincs, szóval szerintem GNU-ék itt direkte ellene dolgoztak a historikus megoldásnak - legalábbis emlékeim szerint sosem kellett azzal szenvedni, hogy külön figyeljünk az üres inputra. Most kéne elővenni azt a DMOS doksit :-) )

/OT

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

De nem is ezért jött létre a -r kapcsoló intézménye, hanem mert sok program hibát dob akkor, ha nincs argumentum. Pl a chmod/chown is ilyen, ha nincs találat, 1-gyel meg hibával térnek vissza, és egy automata scriptnél ez bizony tud fájni. Pláne ha egy nagyobb fájlstruktúrán mászik át a find, majd a xargs által indított bináris eltörik, mert nem kap semmit.

Igazából azt nem értem, miért nem az a (GNU) xargs default behaviorja, hogy ha nincs paraméter átadva, el se indul a hivatkozott program.

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Ennek utánanézek, mármint a +-nak és a -r kapcsolónak is. Az eredeti szkriptben \; van, de mindenképp gyanús, hogy a + vagy a -r esetleg biztonságosabb lehet. Mindenképp érdekel a téma, mert a find -exec kapcsolót több szkriptem is használja. Nem csak ez a chmod-os, hanem pl. van egy olyan, amiben -exec után grep -Il (nagy i, kis L) parancsot futtatok (szerintem ezt nem lehet megoldani xargs-zal), kiszűrve a bináris állományokat, így csak a nem binárisok maradnak a find találati listájában, amit megkap az fzf, hogy plain text editorban nyissa meg a közülük kiválasztottat. Ez utóbbi szkriptet megnézve abban valóban + van a parancs végén. Fel sem tűnt eddig, hogy a két megoldás különböző, míg nem kezdtük feszegetni.

Szerk.: eddig ahogy nézem, az exec végén a ; minden egyes fájlra külön futtatja a meghívott parancsot, + esetében azonban összefűzi a találatokat egy parancssorrá, csökkentve a parancs meghívásásának a számát, így elmossa a különbséget az xargs és az -exec között.

Szerk2: valóban, az xargs -r véd az üres argumentumra hívott parancslefutás ellen, de írja, hogy csak GNU only kapcsoló. Nélküle viszont elég bonyolult lenne megoldani.

Szerk3: megérte vele foglalkozni. Mármint nem a chmod-dal, hanem a find -exec-kel. Átkalapáltam a grep -Il-es szkriptem, ami kiszűri a bináris állományokat a listáról. Rájöttem, hogy nem is az exec vs. xargs volt a lényeg, hanem eleve nem kellett find se, a grep anélkül is alapból végiglépked a struktúrán, meg ezúttal jobban szűrtem ki, hogy melyik mappákban ne keressen (ezt régebben utólag szűrtem ki a listáról), ezáltal közel 2 millió fájlra 10-szerezése gyorsult a szkript. chmod-nál az a baj, hogy nehéz mérni, mert ott nem tudom 1-2 millió fájllal etetni, az egész fájlrendszerre nem akarom ráereszteni, próbaadatnak meg nem akarok 1-2 millió fájlt létrehozni. Kevés fájlra nem biztos, hogy annyira konkluzív lesz a sebességkülönbség, de próbálok mérni egyet.

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

Érdekességképpen mutatok egy 2010. augusztus 4-i mérést (1 darab AMD Athlon(tm) 64 X2 Dual Core Processor 5000+, 4 GB ram, 2 darab 320 GB-os diszk szoftveres RAID1-ben), ha véletlenül mégis eszedbe jutna annak az 1 millió fájlnak a létrehozása (és törlése). Így azt is láthatod, mekkora különbségek vannak (voltak anno) a különböző megoldások között... Nem emlékszem, hogy miért pont 340662 :)

$ time for i in {1..340662}; do touch $i; done
real    62m47.702s
user    3m41.062s
sys     54m28.564s

$ time for i in `seq -w 340662` ; do touch $i ; done
real    59m22.557s
user    3m36.554s
sys     52m25.721s

$ time echo {1..340662}| xargs -P 2 touch
real    0m16.335s
user    0m1.892s
sys     0m16.309s

$ time echo `seq -w 340662` | xargs touch
real    0m14.167s
user    0m2.200s
sys     0m11.477s

$ time echo {1..340662} | xargs touch
real    0m13.194s
user    0m1.484s
sys     0m11.221s

$ time rm *
bash: /bin/rm: Az argumentumlista túl hosszú
real    0m2.827s
user    0m2.404s
sys     0m0.232s

$ time find . -type f -exec rm {} \;
real    44m33.479s
user    1m44.071s
sys     40m35.420s

$ time find . -type f | xargs rm -f
real    0m22.690s
user    0m0.628s
sys     0m21.957s

$ time find . -type f | xargs -P 0 rm -f
real    0m27.501s
user    0m0.968s
sys     0m28.506s

$ time find . -type f | xargs -P 1 rm -f
real    0m22.245s
user    0m0.592s
sys     0m21.005s

$ time find . -type f | xargs -P 2 rm -f
real    0m20.772s
user    0m0.624s
sys     0m26.170s

$ time find . -type f | xargs -P 4 rm -f
real    0m21.400s
user    0m0.780s
sys     0m24.714s

$ time find . -type f | xargs -P 16 rm -f
real    0m23.376s
user    0m0.820s
sys     0m24.598s

$ time find . -type f | xargs -P 32 rm -f
real    0m24.864s
user    0m0.712s
sys     0m25.962s

$ time find . -type f | xargs -P 128 rm -f
real    0m27.514s
user    0m0.856s
sys     0m28.138s

$ time ls | xargs rm
real    0m21.349s
user    0m1.616s
sys     0m19.385s

$ time find . -type f -exec rm {} +
real    0m24.442s
user    0m0.780s
sys     0m22.673s

$ time ./szetdob.sh
real    0m28.707s
user    0m3.320s
sys     0m29.350s

$ cat szetdob.sh
#!/bin/bash

awk '{if ((NR % 10) == 0) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 1) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 2) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 3) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 4) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 5) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 6) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 7) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 8) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 10) == 9) print $1}' lista.txt | xargs rm &
wait

exit 0
$ ls -1 > lista.txt

$ time ./szetdob2.sh
real    0m22.418s
user    0m0.844s
sys     0m29.470s

$ cat szetdob2.sh
#!/bin/bash

awk '{if ((NR % 2) == 0) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 2) == 1) print $1}' lista.txt | xargs rm &
wait
exit 0

$ time ./szetdob4.sh
real    0m20.983s
user    0m1.576s
sys     0m25.438s

$ cat szetdob4.sh
#!/bin/bash

awk '{if ((NR % 4) == 0) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 4) == 1) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 4) == 2) print $1}' lista.txt | xargs rm &
awk '{if ((NR % 4) == 3) print $1}' lista.txt | xargs rm &
wait
exit 0

Kösz szépen, végre valaki, aki agresszió helyett a tényekre koncentrál. Így hogy levezetted, egyértelműen jogos, ezt így ilyen mélyen nem elemeztem ki. Ez már megéri, hogy átírjam. Nem hiába, ezt szoktam is írni, hogy mindig tanul az ember, az a műfaj a CLI/shell téma, ahol mindig van egyel elegánsabb megoldás, állandó mozgó célpont. Nem is szokták elhinni, mikor oldalakon kérdezik emberek, hogy ezt milyen könyvből tanulják, hogy megtanulják, hogy utána hátradőlhessenek, azzal a jeligével, hogy mindent tudnak. Na, olyan nincs.

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

Lefordítom: fogalmad sem volt róla, hogy mit csinál a find exec abban a formában, ahogy te írtad. Amikor megírtam, hogy van jobb, eszedbe sem jutott elgondolkodni a példán sem, amit írtam (vagy nem is értetted?), az meg pláne nem ment, hogy belenézz a man-ba (man chmod, és tudod, amikről te is írtál - u/g/o -, hogy vannak ilyenek is a chmod kapcsán, na, azokat kell használni). De olyan magas lóról tudod osztani az észt, hogy az gyakran elképesztő...

De, fogalmam volt, mint írtam, eleve beszédes opció, manját is néztem, hogy a {} mit csinál, más szkriptem is használja. Viszont kiderült hogy a + \; különbségéről tényleg nincsen, és ez a -r-es javaslat is új jelenleg. Ez egy olyan apróság, ami felett eddig elsiklottam, de nem mintha te annyira csípőből vágnád, mert nem látom, hogy az érdemben felvilágosítanál akkor a részletekről. Mondjuk azt eleve kötve hiszem, hogy te is fújsz minden létező parancsnak minden létező kapcsolóját, főleg, ha többféle rendszeren is kell használni, ahol egyik-másik nem is biztosan létezik. Eleve csak a bash-nak egy 4+ ezer sornyi a manja, és akkor ott van még több száz kisebb parancs, aminek adott esetben csak 1-2, de szépen összeadódik. Én is csak azoknál tudom, amelyek vagy annyira mindennaposak, vagy már volt dolgom vele.

Az ugo+-rwx-et meg nem azért kell használni, mert magas lóról osztom az észt, hanem hosszú távú megfigyelésem, hogy a legtöbben csípőből tolják ezeket a 3-4 jegyű oktális értékeket, értsd: nem gondolják át. Ennek én magam is áldozatul estem jó 11 éve, amikor kezdő linuxos voltam, én emlékeim szerint valami régi magyar unixos könyvből szedtem fel, még az internet előtti időkből, aztán a saját káromon a gyakorlat bizonyította be, hogy miért nem jó ötlet. Tényleg csak azért mertem megemlíteni, mert a kollégánál is ilyesmire gyanakszok a háttérben. De nem kell nekem elhinni, ha te írod, a te hangod mélyebb, az valóban több hitelt fog adni neki, és csak utána szabad alkalmazni. Ahogy viszont érzékelem, az ugo+--rwx metódust te is jóváhagyod, szóval innen lapozhatunk is.

Mondom, javíts ki, de akkor írd meg a javítást is személyeskedés helyett. Előre is kösz.

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

Érdemben felvilágosítottalak már az első hozzászólásommal, hiszen csupa olyan dolgot mondtam, amiről fogalmad se volt. És benne volt a megoldás is: rtfm :) Ennél részletesebb megoldást vársz egy ilyen egyszerű kérdésben? Úgy akarsz tanulni, hogy valaki magyarázza el részletesen a man chmod-ot? Ilyenkor hol van a tanulni akarásod? Eszem ágában sincs megírni a megoldást, és ha azt hiszed, azért, mert nem tudom, akkor még annál is butább vagy, mint amilyennek mutatod magad.

legtöbben csípőből tolják ezeket a 3-4 jegyű oktális értékeket, értsd: nem gondolják át.

Látod, ez megint olyan megfellebbezhetetlenek tűnő kinyilvánítás részedről, amitől az embernek kedve támad - ahogy te fogalmaztál - szívlapáttal tarkón vágni :) És a hasonlókat bőkezűen, számolatlanul szórod minden *nix-os témában, ezért gondoltam, hogy - ha már így beleszaladtál a málnásba, akkor - megmutatom neked ezen a nagyon egyszerű példán át, hogy a tudásod - finoman szólva is - sekélyes. Úgy lehetne finomabban megfogalmazni, hogy a tudásnak azon a szintjén állsz, hogy azt sem tudod, hogy mit nem tudsz :) Egyszóval: szerényebben...

Nem, semmilyen dolgokat nem mondtál, nem tetszett egy konkrét 2 soros megoldásom, arra utalgattál, hogy neked megy rövidebben, csak épp elfelejtetted megírni azóta is, ügyesen kerülöd. Én leírtam, hogy milyen opciókat zártam ki és miért. Abban bűnös vagyok, hogy én ezt már anno végigzongoráztam, amit itt végigveszünk, de nem írtam le kommentezve a kódban, most ezt pótoltam, hogy ha később belekötne más is, akkor látszódjon.

A másik része nem kinyilvánítás, hanem megfigyelés. Érted, nem így lenne, akkor találkoznánk ilyen gányolt mappákkal, amikbe én is számtalanszor belefutottam másoknál, meg a topikindító is, meg számos tanfolyás, tutorial anyagában látom. Nem véletlen ám. Erősen meglepne, ha nem lenne ebben igazam, és más állna a háttérben (hibás felcsatolás, Samba megosztás, stb.). Az ugo megoldás nem csak szelektívebb, de beszédesebb, egy szkriptben mindenki levágja, hogy mit csinál. Ebbe a hibába sok fejlesztő is beleesik, hogy szeret tömör, absztrakt kódot írni, amiről aztán később kb. senki se érti, hogy mit csinál, közben meg ha olvasható, átlátható kódot írna, esetleg más is karban tudná tartani, debugolni.

Egyébként értem, hogy téged mi zavar most, azt várod, hogy a chmod a-x,a+X változatot írjam, hogy megtaláltam, de megint nem lenne igazad. Erről azt gondolnád, hogy a find -d/-f -exec chmod 644 illetve 755-öt kiváltja. Csak látszólag, futtatható jogokra igen. De pl. ha begányolt setuid, vagy sticky bit is van a cuccoson, akkor megint csak félúton vagy vele, mert azokat nem szedi le, és abban a tekintetben nem kezeli külön a mappákat a fájloktól. Nem véletlen, hogy ezt a find megoldást mindenki alkalmazza, mert ez mindent levisz az adott mappaágról, visz mindent, mint Kamaz a kereszteződésben, mindenhol működik. Azért is mondtam, hogy sajnos van a gányolásnak az az szintje, ami ellen te eleganciával meg hatékonysággal nem tehetsz semmit, és atomot kell dobni az egészre nagyon durván, be kell hozni a find-ot, a régimódi oktális nagyágyúkat, pont az ilyen esetekre valók. Ha ez így lenne, hogy elég minden esetben a -x és +X, akkor nem találták volna ki, vagy deprecated jelzővel kiszedték volna már vagy 20 éve, és nem csak a visszafelé kompatbilitiás az oka.

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

azt várod, hogy a chmod a-x,a+X változatot írjam, hogy megtaláltam, de megint nem lenne igazad. Erről azt gondolnád, hogy a find -d/-f -exec chmod 644 illetve 755-öt kiváltja. Csak látszólag, futtatható jogokra igen. De pl. ha begányolt setuid, vagy sticky bit is van a cuccoson, akkor megint csak félúton vagy vele, mert azokat nem szedi le, és abban a tekintetben nem kezeli külön a mappákat a fájloktól.

Az ilyenre mondják, hogy nem rossz, de a jó (megoldás) nem ilyen :)

Hagynám, hogy kínlódj még egy darabig, de úgy érzem, hogy ennél többre nem futná, és megoldás nélkül maradva azt hinnéd, hogy neked van igazad :) A megoldás ennyi:

chmod -R a=,a=-s,u=rwX,go=rX dir

Mindent visz, setuid, setgid, sticky, x jog fájlokon... (Csak zárójelben: a setuid, setgid és sticky biteket már kínodban keverted bele, mert az általad használt find exec ezek egy részére semmilyen megoldást nem kínál. Jaj, a setgid eszedbe se jutott...)

Láthatóan a man (és a különböző segítségnyújtások) alapján se sikerült összeraknod.

Szóval szerényebben. Sokkal szerényebben...

( kikadff v | 2025. 01. 28., k – 08:22 )

ls -l konyvtar_neve, ls -l konyvtar_neve/.., rm -v fajl_neve mit mond?

ls -l /path/folder
total 80
drwxrwxrwt+ 2 777 user 4096 Jan 28 06:42 .
drwxrwxrwt+ 5 777 root 4096 Jan 28 07:20 ..
-rwxrwxrwx+ 1 777 user  238 Jan  3 11:06
-rwxrwxrwx+ 1 777 user  288 Jan 27 08:05 
-rwxrwxrwx+ 1 777 user  770 Jan 22 13:39 
-rwxrwxrwx+ 1 777 user  253 Jan  6 12:56 
-rwxrwxrwx+ 1 777 user 2123 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user 2124 Jan 17 10:07 
-rwxrwxrwx+ 1 777 user  203 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user 2668 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user  190 Jan 23 14:55 
-rwxrwxrwx+ 1 777 user  169 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user  644 Jan 20 11:14 
-rwxrwxrwx+ 1 777 user  176 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user 4905 Dec 15 10:41 
-rwxrwxrwx+ 1 777 user 5851 Jan 28 06:42 

 ls -l /path/folder/..                       
drwxrwxrwt+ 5 777 root  4096 Jan 28 07:20 .
drwxrwxrwt+ 8 777 root  4096 Sep 13 12:12 ..
drwxrwxrwt+ 2 777 user  4096 Jan 28 06:42
drwxrwxrwt+ 4 777 user 12288 Jan 17 10:28 
drwxrwxrwt+ 2 777 user  4096 Dec  4 12:28

rm -v /path/folder/file
rm: cannot remove '/path/folder/file': Operation not permitted

Igen, ACL-el megy alapvetően a story.
Az történt hogy a user létrehozott egy alkönyvtárat a saját könyvtárában és rátett egy sticky bit-et, ami keresztbe tett az ACL-nek.
Az egész egy kényszerhelyzet szüleménye, ez így alapvetően alkalmatlan filekiszolgálónak.
Te adtad alepvetően az ötletet, elvesztem a UNIX jogosultságok, ACL, Sticky bit, Immutable együttesének forgatagában.

Nem figyeltél a kérdésre. Az a kérdés, hogy az normális-e hogy a user jogosultság a 777-es UID-hoz köt, a csoport meg a user/root csoporthoz.

Az a gyanú horgadt fel bennünk ugyanis, hogy valaki a chmod -R 777 izehoze helyett a chown -R 777 izehoze parancsot adta ki. Ez utóbbi is értelmes, de mást jelent (Linuxon, meg gondolom Unixon is, alaovetően nem vagy köteles egy user/group nevét használni jogadásnál, használhatod a UID/GID-jét, ha az kényelmesebb).

Blog | @hron84

valahol egy üzemeltetőmaci most mérgesen toppant a lábával 

via @snq-

Nem, ez valóban nem normális – de nem tudom kezelni vagy korlátozni a usereket abban, hogy az általuk létrehozott fájlokhoz milyen tulajdonost, csoportot és jogosultságokat állítsanak be.
Az ACL miatt a tulajdonosnak és a csoportnak ebben a use-case-ben nincs kimondottan nagy szerepe, itt a chmod 777 is elfogadható.

Nem találtam jobb megoldást, mint írni egy szolgáltatást, amely az inotify-ra alapozva érvényesíti a kívánt jogosultságokat és tulajdonosokat.