Max. mekkora lehet a sudoers file?

Linux-kezdő

Konkrét, gyakorlati tapasztalat érdekelne, hogy kinél mekkora a sudoers file, és van-e valami gond vele. Olyan tízezer sor felett érdekes a dolog, akinek kevesebb van, ne fáradjon :)

Az a terv, hogy sok, több ezer gépre ugyanazt a sudoers dobnám le, így nem kellene azon ügyeskedni, hogy erre a gépre ez való, arra a gépre meg az. One size fits all.

Igen, tudom, hallottam a Google-ről, meg ezt is megtaláltam, de ennek ellenére ha valakinek van akár negatív, akár pozitív tapasztalata, azt örömmel látom.

( persicsb | 2021. 07. 28., sze – 13:25 )

But why? 

Úgy értem, mi az a scenario, ahol több ezer gépet kell menedzselni kézzel, emiatt kell sudoers minden gépre?

ja meg freeipa, meg whatever hogy kozponti management legyen. Meg az is fura ha tobb ezer sor egy sudoers, mert ugy nem usereknek adunk jogosultsagokat hanem group-oknak altalaban multiuser-es kornyezetben.

De az is erdekes igy a 21. szazad hajnalan hogy tobb szaz felhasznalot engedunk belepni egy szerverre az OS-be, hogy dolgokat csinaljanak es nem szolgaltatashoz engedjuk oket, amikben sokkal szofisztikaltabban be lehet allitani hozzaferes kezelest (rbac, stb.)

Kicsit olyan 80-as evek feelingem van. Pedig akkor sem voltam mar mai csirke. :D

( gelei v | 2021. 07. 28., sze – 13:38 )

Linux security-ben meglehetősen laikus vagyok, de ezt úgy érted, a szervezetben több tízezer fő van, akinek local admin jog kell az összes gépre, de ez a több tízezer fő nem a userek teljes halmaza? Erre tudsz valami példát, hogy miért így lett?

(hidden subscribe)

hat belep a "single point of truth" szerverre, ott torli amit kell, majd mindenhova atmasolja :D aztan osszerakja a kicsi kezet hogy manska is ez legyen a kozponti szerver :D

vagy NFS-re rakunk mindent

vagy inotify-al viszgaljuk az allaomanyt es triggerelunk egy copyovereverwhere.sh-t, ami mindenhova atmasolja (na jo ez mar majdnem automatizmus)

vagy megy git-be merge request-el, majd triggerelodik egy pipline hogy teritse le mondjuk puppet/nasible/whatever-rel (na ez automatizalva a kezimunka)

easy as pie

De semmi esetre sem hasznalunk 5+ user felett kozponti managementet :D ... azok luzerek, ne is irjanak

( Raynes | 2021. 07. 28., sze – 16:22 )

Szerintem nincs méretkorlát, de több tízezer soros sudoers fájlnál erősen gyanakodni kell, hogy valamit nem jól csináltok, más megoldási módozatok kellenének. Olyan sok sor abnormális, áttekinthetetlen, kezelhetetlen.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( pif73 | 2021. 07. 28., sze – 19:07 )

Szerintem a

#include

directíva a barátod, s akkor nem kell egy óriási fájl, hanem több kisebb, pl. csoportokként egy.

Ja, ez meg a másik, amit el is felejtettem írni. Hogy oké, hogy 10k user, de csoportokba lehet szervezni. Még akkor is, ha már elve csoportokban vannak, de mondjuk másodlagos csoportokba is betenni őket, hogy akinek egyenlő szintű sudo-jogai vannak, az egy csoportba kerüljön, vagyis legyen benne abban is, és a sudoers fájlban ezekre a csoportokra hivatkozni jogkiosztásnál, nem közvetlenül egyes userekre. Az egész csak szervezés kérdése, nem kell ide 10k meg 1M soros fájl, amit ember nem tud áttekinteni. Ha valami forráskód meg configfájl túl nagyra hízik, az mindig gányolásnak a jele. Mindig!

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

( YleGreg | 2021. 07. 29., cs – 16:07 )

Ketlem, hogy tobb 10k eltero jogosultsagu accountot kell kezelned, kiveve ha ez valamilyen automata teszt rendszer resze, ami pont errol szol.

A felhasznalokat csoportositva (AD csoportok, sssd -vel feloldva) kezelheto meretu listakat lehet letrehozni, es gepcsoport szerint lerakni.

Van sok egyforma jogosultsag, vagy tenyleg szinte mind kulonbozik a tobbitol?

( kecske | 2021. 07. 30., p – 14:26 )

... kinél mekkora a sudoers file, és van-e valami gond vele. Olyan tízezer sor felett érdekes a dolog, akinek kevesebb van, ne fáradjon :)

Azt a rohadt. :) Viszont ez nekem erosen az XY problemara hajaz. Itt (angol) es magyarul itt.

Persze. A környezetet nem írhatom le, illetve lehet hogy leírhatnám, de nem fogom.

A jelenlegi leghosszabb sudoers 214 soros. Azoknak, akik nem láttak a 'ALL=(ALL) NOPASSWD:ALL' -nál bonyolultabb sudót: nem csak userek lehetnek benne, sőt.

Igazság szerint nem várom, hogy az "én időmben" (mondjuk tíz éven belül) ennél nagyságrendekkel hosszabbra nőne, viszont a környezet miatt nem is teljesen lehetetlen. Egyszerűen csak arra vagyok kíváncsi, amit kérdeztem is, hogy okoz-e problémát, de ezt úgy látom hogy senki nem tudja.

Igen, nem csak userek lehetnek benne, hanem csoportok, meg egyes utasításokra bontva futtatási jogok, jelszókérés vagy annak kizárása, stb.. Az alap sudoers a legtöbb disztrón a kommentekkel kb. 100 sor, kb. 200 sornál nagyobb sudoers-t sehol nem láttam még. Szerintem pár ezer sorig tuti nem lesz gondja, addig meg maga a fájl lesz olyan áttekinthetetlen, hogy zavarni fog, és inkább átszervezed úgy a usereket, csoportokat, hogy tisztább séma mentén legyen szabályozható a futtatási jogkör nekik. Elméletileg még azt is megkockáztatom, hogy 4 gigáig sem lenne gondja a sudoers-nek, efölött is csak elméletileg, ha valami 32 bites pointert vagy más memóriatakarékos hekkelést benne hagytak a kódban, vagy 32 bites rendszerről van szó. Az, meg hogy mi lesz a te időd után, ne foglalkozz, azzal bosszankodjon az utódod, ha sikerül túlgányolniuk a sudoerst, akkor így jártak, majd megoldják. Ezen amúgy is felesleges paranoiázni, hogy mi lesz ha. Legyen mentés mindenről, és legyen mindenre tartalék hagyva, elegendő partícióméret, fájlrendszer, elég inode, észszerű rendszerbeállítások, ne legyenek legacy gányolások, akkor nagy gond nem lehet. Amúgy is rossz sudoers-nél a maximum probléma, amibe belefutsz, hogy egyes usereknek nem fog működni a sudo, akkor nyomatsz helyette root su-t, amíg meg nem oldod. Olyan nagy problémát semmiképp nem okoz, hogy maga a rendszer legyen működés és bootképtelen.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

Mert minek foglalkozzon? Főleg, hogy úgy kezdtem, hogy egyedi gányolásoktól mentes, észszerű defaultos rendszerről van szó. Egyik rendszert sem terveztek arra, hogy örökké fusson, az idők végezetéig. Valamikor úgyis hozzá kell nyúlni, de ha már nem lesz alkalmazásban az illető, akkor mit érdekli, hogy mi lesz azután. Szerinted az elődödet érdekelte? Vagy annak az elődjét? Nem neked dolgozott. Épp ezért nincs sehol örök/végtelen support sem, csak x évre, aztán nem érdekel senkit. Ja, lehető legrosszabb hozzáállás, ha akarod, te támogathatsz dolgokat valakinek ingyen örökké, másnak ez nem fogja megérni.

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

De pont azt mondom, hogy nem hagyunk szart. Mert nem gányolunk. Meg azért vannak a kommentek is a sudoers-ben, nem dísznek, lehet szépen kommentelni, dokumentálni mindent, verziókezelni, stb.. Én eleve nem is gondolkodnék emiatt sok ezer soros sudoers-ben, pont ezt írom, mert áttekinthetetlen, nem csak az utódunknak, hanem az embernek saját magának is, ha x év múlva elő kell venni, és már nem emlékszik, hogy mi miért volt benne. Ezért fontos a tiszta kód, jó kommentek, jó dokumentáció, jó koncepcionális szervezettség. Mert az az „utód” könnyen lehetünk saját magunk is. Ezt én is a saját káromon tanultam meg, mikor még kezdőként írt gányolt kódokat kellett elővennem, és láttam, hogy milyen szar, milyen használhatatlan, nyűg volt újraírni, a rest kétszer fárad, stb..

Pont ez a baj most a régi IBM mainframe meg cobolos kódokkal is, régen egyszer összegányolta valaki, ilyen low level drum/core memory, meg legacy tape drive, és lyukkártyás hekkekkel, és egy mai modern fejlesztő, hiába is tanul meg cobolul, az életben meg nem fejti, hogy mit csinál a felismerhetetlenségig gányolt kód, de ennek ellenére pl. sok bank és állami szerv még mission critical szinten épít ilyen régi kódokra. Erre régen szükség volt, mert gyenge volt a hardver, kevés az erőforrás, minden bájton és KB-on spórolni kellett, hogy használhatóan fusson, de ez már régóta nem játszik. Anno nem véletlen, hogy a Unix is olyan tömör volt, 2-3 karakteres hieroglif parancsok, hibátlan lefutás esetén jellemzően 0 output, legfeljebb 1 exit code, minden 7 bites ASCII plain text alapon, semmi nem volt bő kommentekre és részletes hibaüzenetekre eresztve, nem volt GUI, de ennek ellenére törekedtek rá, hogy jó dokumentáció, manual legyen hozzá, moduláris legyen, legyen könnyen portolható más rendszerekre, ezért is tudott életképes maradni és fentmaradni. vi, vim, Emacs, C, stb. is ezért életképes a mai napig, mert hasonló elveket követ, rugalmas, jó öndokumentáció, stb..

“A computer is like air conditioning – it becomes useless when you open Windows.” (Linus Torvalds)

húha.. itt azért van gond.. nyilván a topic nyitó több 100X soros sudoers-e beleillik valami projektbe, amit nem árt azért ledokumentálni, hogy mi miért is van.

Ha szerinted úgy kell hagyni a picsába az egészet, mert ez jön le a hozzászólásodból, akkor az téged minősít.

Nyilván ha te "összetákolsz" valamit, akkor ahhoz 0 dokumentációt adsz majd át a következőnek, még egy árva "txt" fájlt se hagysz neki hogy esetleg kiinduló pontja legyen.
Ha ez így van, elég siralmas lehet utánad átvenni bármilyen melót is, de megnézném te hogy veszed át az ugyan ilyen melót ...

Gondolom nekiállsz újratervezni az egészet és akkor minden szép és jó lesz. Lerakod a sz.rodat otthagyod, felmondassz, azt b.sszon valaki más vele tovább. :) Remek hozzáállás :)

korulbelul 10+ eve nem lattam olyat, hogy a szerverekhez direkt hozzaferest engedunk falhasznaloknak, nemhogy parancsokat futatgassnak rajta. Tobben is irtunk megoldast arra, hogy ezt a szarkupacot el kell felejteni es helyette mashogy megkozeliteni a problemat. Ha az ugyfel ezt igy, ilyen formaan akarja, akkor azt ott lehet neki nyugodtan hagyni ilyen formaban. Es lelepni. Ez akkora antipattern, mint a haz. Nem lehet, hogy "beleillik egy projektbe", mert akkor annak a projektnek reszeltek (nagyon rossz dontesek szulettek akkor az architektura tervezesenel).

Félreérted, nem valós, hanem egy elvi síkú problémáról megy az agyalás. Ami nem feladat, azt nem kell megoldani. Nem csak azért, mert nem fizetik ki és elvisz időt, hanem azért, mert új hibákat hozhat be. 

Szvsz, ha ebben lehet valós kockázat, akkor inkább valami monitorozásra kell rákötni, hogy jelezzen, ha valamely kritikusnak gondolt szint fölé nő. Amikor pedig tényleg meg kell oldani, akkor már ésszerűen, lespecifikáltabban, dokumentáltabban kell rendesen megcsinálni.