Sudo te drága.. De sokat kell érted fizetni időnként :)

A sudo nevű utility-t szerintem nem kell senkinek se bemutatnom.
Segítségével (minimum féldisznóért) root hozzáférést kaphatunk kedvenc adminisztrátorunktól az adott (természetesen teszt) rendszerünkhöz (NOPASSWD-s rule-al, mert jelszót beírni senki nem szeret :)), így szabadon garázdálkodhatunk és nézelődhetünk, hogy ha valami gáz van a kódban (avagy "De hisz ez még tegnap működött!").
Persze azt se szabad elfelejteni, hogy ezen eszköz révén némileg le tudjuk korlátozni az olyan usereket is, akiknek helyenként root jogosultság kéne, hogy elindítsanak valamit ("Hogy hogy nem képes a WAS support team elindítani a 80as portra bindelő WAS-t root hozzáférés nélkül? Felháborító!")

Lényeg ami lényeg: AIX/Linux alatt ez a progi több mint kötelező, hacsak némileg is törődünk a gép biztonságával. Persze ennek telepítése után se lesz kolbászból a kerítés, sőt, még plusz melót is vartunk a nyakunkba azzal, hogy a /etc/sudoers-t karban kell tartani, de hát istenem, ki mondta, hogy a security fenékig tejföl?

Az issue amivel jelen esetben sikerült szembetalálkoznom kb úgy kezdődött mint minden szokásos "ÚR ISTEN, SECURITY HOLE!!!!" jellegű felkiáltás:
Az IBM által hivatalosan elérhetővé tett sudo 1.6.9p23-as szinten van, viszont pár napja felütötte a fejét egy olyan hiba, ami ezt a verziót is érinti, a customer meg persze az ilyeneket olvasva sikoltozva kiabálja, hogy azonnal tedd fel a javítást. A probléma persze csak az, hogy a hivatalos IBM-es csomag nem elérhető, ergo hivatalos javítást nem tudsz feltenni, ha akarsz se. Customer-t ez persze nem hatja meg, a sudo amúgy sem IBM product, forgass egyet magadtól, az annyira amúgy se nehéz..

Így is lett. Az ember forgat magának 1.7.9es csomagot (hivatalos IBM support innentől sudo-t ne akarjon supportolni :)), customer örül, And so once again the day is saved. Murphy persze hogy erre az alkalomra vár és bedobja az "I don't think so" kártyáját, aztán az admin már meg se lepődik, amikor a customer ismét telefonál, hogy "Őőő.. ez most miért nem megy"? *sigh*

A történet kb az alábbi: Az 1.7.9es sudo óta bejött AIX alatt egy regresszió az alábbi change miatt:
- If none of the standard input, output or error are connected to a tty device, sudo will now check its parent's standard input, output or error for the tty name on systems with /proc and BSD systems that support the KERN_PROC_PID sysctl. This allows tty-based tickets to work properly even when, e.g. standard input, output and error are redirected to /dev/null.

Ez AIX alatt kb úgy néz ki, hogy amennyiben nincs tty device-od a sudo hívásakkor, úgy pityiszt kapsz az orrodra, nemhogy lefutott parancsot.. Persze az ember valami hibaüzenet féleséget várna minimum, de a sudo-val meghívott process ez helyett szimplán csak hang-el, és nem csinál semmit.. Ez persze kifejezetten kellemetlen amikor a customer által futtatott rendszer egy DB2 osztott cluster, ami rah parancsokat használva szeretne a node-okkal kommunikálni, ami persze hogy tty nélküli kulcs alapú ssh chanelleket használ(na), így nem csoda ha a rah parancs is beáll, mint a gerely.

Mondanom se kell, hogy az ember ilyenkor mennyire fel van dobva, és már a telefonálás pillanatában elönti az adrenalin, és a tettvágy, hogy egy ilyen kaliberű hibát kinyomozzon anélkül hogy tudná mit és hol keressen :)
Röviden: pár óra kellemes orális szerelmeskedés (értsd: szopás) után megvan, hogy valószínű az új sudo a hibás, visszarakod a régit, és láss csodát, minden megy ahogy kéne..
Csak a rendszered lett megint non-compliant, tehát amit nyertél a réven, azt veszted a vámon, mert valahogy csak meg kell nézni, hogy mi a fene okozza ezt a hibát..

Újabb kellemes órák, újabb kellemes tesztelgetés, sudo.c turkálás, és hasonló jóságok után az ember eljut oda, hogy a hiba tényleg az 1.7.9ben jött be ( 1.7.8p1en még minden szépen megy), és ha a tty kezelési részt kicsit visszapiszkálja, akkor megy is minden szépen:

devel_box@root:/ # diff /tmp/sudo-src/sudo-1.7.9.gabor/sudo.c /tmp/sudo-src/sudo-1.7.9/sudo.c
628,631c628,630
<
<     if ((p = ttyname(STDIN_FILENO)) || (p = ttyname(STDOUT_FILENO)) ||
<         (p = ttyname(STDERR_FILENO))) {
<         user_tty = user_ttypath = estrdup(p);
---
>
>     if ((p = get_process_ttyname()) != NULL) {
>       user_tty = user_ttypath = p;

Oks.. akkor most már bizonyított: software bug.. nyissunk rá ticketet, aztán a fejlesztő majd megszakérti mi is a probléma -> Bug #557 a sudo-s bugtrackerben, megidézlek!

S lőn fél napon belül megvilágosodás: Valóban regressziót találtunk, sőt régebben már más is jelentette ezt a problémát, csak nem az 1.7-es, hanem az 1.8as szériához. Külön öröm, hogy a következő 1.7.10es verzióban már ez is javítva lesz, sőt, már a béta el is érhető, úgy hogy akinek ilyen igényei vannak, az használhatja azt..

A customer meg döntse el, hogy mit és hogy is akar ezek után :) Aki meg hasonlóval szív, az tegye vissza a régit, vagy használjon béta release-t, amíg az új ki nem jön :)