sice to tady řešíme "ne nutně C++", ale stejně... současně s C++ 11 se objevilo i C11, takže je to celkově zajímavé sledovat

Stroustrup reveals what's new in C++ 11 | Application Development - InfoWorld
http://www.infoworld.com/d/application-development/stroustrup-reveals-whats-new-in-c-11-187051?page=0,0

BLAMI: tohle je jistě maximálně ontopic... je to ale API ke knihovně, která by ušetřila volání commandline API, budiž... ale je k tomu i nějaký uživatelský frontend?

co si zákazníci žádají, je minimálně restart, jako bonus pak 2-3 další věci. spouštět to přes commandline je relativně snadné... faktem je, že vlastně by stačil přímo přístup přes ssh na xen konzoli, ale já to chci udělat přeci jen nepatrně elegantnější - proto snaha dobastlit tam ty ncurses...

já se o tom asi chci bavit s někým jiným, než s id REDGUY, ach jo...

ale je fakt, že ncurses taky moc nevěřím. spíš se to udělá, že ta samotná akce bude provádět přes sudo a ta věc s ncurses poběží sama o sobě pod normálním userid. (ono to má i jiný důvod: poslední zbylé bezpečnostní opatření pro ssh je potom mít roota bez hesla, jen přes su od vybraných userů - a zakázat přes ssh login bez hesla: jenže my tam root heslo zřejmě stejně potřebujeme, z určitých důvodů)

(podotýkám, že v současné verzi to dělá JENOM reboot a žádné ncurses tam nejsou)

XCHAOS: že to administrátor neumí nainstalovat - ach jo. To co jsem psal _vubec_ neni o tom "že to administrátor neumí nainstalovat". Bud to nechapes, nebo strawmanujes. Ale to je jedno. Kdo chce kam, pomozme mu tam. Nezbyva nez pogratulovat k tomu, jak dobre sis dokazal zaridit ze ti za tohle je nekdo ochotnej zaplatit 8))

A ne, poustet nejakej ncurses bastl, navic napsanej tebou, pod rootem, kdy k nemu ma pristup kdejakej uzivatel a na masine hostujici VM pro kdovikolik zakazniku bych si _fakt_ netroufl. Kdyz uz, tak webova sluzba s proverenou autentifikaci, omezenim request rate a jednoduchy ale bytelnym suid skriptem. Nebo jestli nemas rad webovy sluzby, tak i pres to ssh, ale zase s tim ze se uzivatel loguje na jeden vyhrazenej neprivilegovanej ucet, spolecnej pro vsechny zakazniky s naslednym rozlisovanim pres ssh klic. Ale proc to delat pricetne kdyz to jde udelat vizionarsky, ze? 8))

REDGUY: to je diskutabilně pravda, nicméně tady je spíš kritické mít v sshd povolené přihlášení roota (protože se to dává jako shell uživatelům s taky-uid-0). tedy když už se to vůbec spustí (což není samozřejmé), pokládám to fakt za triviální.

ale zase nechci, aby se ten uživatel vůbec mohl dostat na šel. (jako jo... přes nějakou on-demand konfiguraci sudo by to mělo jít taky, diskutabilně... tohle je záležitost programování, ne administrace... ale v zásadě nejbezpečnější mi to přijde udělat v C, než jako nějaký interpretovaný skript v něčem, kde budu doufat, že uživatel ten skript nemůže nějak přerušit...). takže i když by ten uživatel měl vlastní uid - pořád bych použil tenhle skript, akorát by se to volalo přes sudo. (což možná přeci jen udělám)

ano, zajímají mi na tom ty bezpečnostní aspekty. ne trollování o chybějící chybové hlášce - tady není potřeba řešit čistě hypotetický problém že to administrátor neumí nainstalovat - tady se řeší, jestli je nahrazení shellu jednoúčelovou binárkou potenciální bezpečnostní díra, nebo ne.

XCHAOS: brrr, to menu je ohavné... to jsem fakt čekal něco aspoň na úrovni těch textových ansi-barevných menu co dělá program dialog... uff

XCHAOS: Hele, nejde o to jestli se to instaluje blbuvzdorne nebo ne. Jde o to, ze kdyz neco poustim na produkci, tak z toho chci dobrou diagnostiku. Protoze kdyz se pak neco casem posere, tak proste takovahle nulova diagnostika znamena, ze stravim mnohem vic cashu hledanim co se vlastne rozbilo. Nekdo omylem smaznul /usr/sbin/xm? Tak kurva ten program musi rict "Nepodarilo se mi spustit /usr/sbin/xm, protoze file not found", ne tise pokracovat a tvarit se ze je vsechno v poradku.

A btw: extra binar a jemu odpovidajici extra polozka v /etc/passwd pro kazdyho uzivatele, navic aliasovana na roota? HAHAHAHAHA.

REDGUY: no v podstatě... v té fázi ve které to je, se opravdu nepředpokládá, že by se to instalovalo nějak "blbuvzdorně" - protože jméno restartovaného serveru se před kompilací píše přímo jako #define, tak tak opravdu není ve fázi, kdy bych řešil chybové hlášky: kdo to umí editovat a zkompilovat, měl by umět i zkontrolovat co do toho napsal. asi bych v první řadě uvažoval o externím konfiguračním souboru, a pak teprve o chybových hláškách, kdybych řešil tohle...

to, že to případně skončí bez chybové hlášky i čehokoliv jiného, je sice asi pro někoho potenciálně nepříjemné... ale není to zrovna bezpečnostní díra. spíše jsem se chtěl ujistit, že neexistuje žádná mizivá pravděpodobnost, že sshd z nějakého obskurního důvodu na základě nějaké nedokumentované enviroment proměnné spustí místo shellu uvedeného v /etc/passwd nějaký naprosto náhodně zvolený program... prostě uvažuju, jestli je bezpečné pouštět uživatele až takhle daleko.

(ale zase moc netuším, jak jinak to udělat... především jim vůbec nechci dávat ssh... samozřejmě čistší je možná povolit jim sudo na tu jedinou binárku a nepouštět tohle pod rootem? ... nevím, nejsem admin...)

XCHAOS: a jakou jinou chybovou hlášku navrhuješ vypsat - hm, nevim. Co treba "Oh shit, something's borken"? Anebo, pozor, opet vysoce radikalni myslenka pouzivaji super-advanced techniky, co treba pouzit funkci perror? Ale pravda, to je zase jedna z tech novinek co jsou v unixu jenom par desitek let 8))

hostitelský stroj, na kterém by se nepodařil např. fork() by v první řadě ani po navázání ssh spojení nebyl schopný spustit tenhle skript Jo, jasne. Protoze mezi spustenim tohohle bastlu a pokusem o fork se nemuze stat nic co by forkovani znemoznilo. A execl se povede taky vzdycky, protoze ten spoustenej binar je vzdycky na svym miste a vzdycky ma spravny prava a...

REDGUY: no, popravdě... hostitelský stroj, na kterém by se nepodařil např. fork() by v první řadě ani po navázání ssh spojení nebyl schopný spustit tenhle skript... a jakou jinou chybovou hlášku navrhuješ vypsat? co se dále může nepodařit?

je fakt, že lidi tohle budou mít tendenci spouštět, když se něco rozbije. na hostitelském serveru s XEN virtuály ale neběží kromě toho sshd nic... a když se tam něco rozbije tak, že ani fork() ani exec(), tak se to především ani nedostane tak daleko, aby se tenhle skript spustil.

takže buď ti leží na srdci duševní zdraví tak hloupého admina, který si to nainstaluje, aniž by chápal, co a proč vlastně dělá... a nebo patříš k těm lidem, co se neustále vrací z ulice zpět do bytu zkontrolovat, jestli vypli vodu v koupelně, zhasli a zamkli :-)

ok... tak viz nový http://teckacz.arachne.cz/xchaos/files/xen-reboot.c
trochu jsem tam vyladil ty sleepy, to jsem chtěl už dřív, ale až teď jsem si na to vzpomněl... je blbost tam zběsile bez čekání smyčkovat, a čekat než něco skončí, že jo.

XCHAOS: Mozna je to prilis radikalni myslenka, ale coz takhle vypsat chybovou hlasku? Nebo nastavit nejakej navratovej kod? Ale mozna je to moc radikalni, navratovy kody se v Unixu pouzivaji jenom asi ctyricet let 8))
A mozna v behu programu tupe nepokracovat kdyz se nejakej ten execl nepovede? Chapu, jsou to dost advanced techniky, ale mozna by to stalo za uvahu 8))
(btw, "pro klienty", takze ti za tohle nekdo zaplatil? Dobrej dzob 8) )

ANT_39: ale no jo furt, to byla rychlá redakční úprava, abych neodhaloval jméno klienta :-) zatím se to kompiluje na míru každýmu klientovy, právě proto,že to podsouvám jako shell.

popravdě, případné bezpečnostní díry téhle koncepce by mě fakt zajímaly - běží to pod uid 0, ale teoreticky... pokud není díra v tom závěrečným xm console....

REDGUY: a co v tomto případě navrhuješ dělat? u neinteraktivního skriptu?

Nevim, jestli je to umysl, ale...

#define SERVERNAME "servename"


XCHAOS: Jojo, ignorovat navratovy hodnoty a pokud se neco pokazi tak tise failovat, to dava smysl 8))

Je taková užitečná legrácka, co jsem teď "vyvinul" pro naše klienty. Pro vserver totéž bylo triviální - u Xenu ovšem byla finta v tom, že po vykillování a reinicializaci právě bylo nutné ještě přesměrovat konzoli na stdout, aniž by člověk použil něco volání system():

http://teckacz.arachne.cz/xchaos/files/xen-reboot.c

Minimálně si z toho uděláte přesdstavu, jak asi vypadá implementace části funkčnosti shellu "uvnitř" (ostatně - shell je přece taky napsaný v Céčku :-)

Proč je to v Céčku? Inu.... (cituji z /etc/passwd):

servername-reboot:x:0:0:Reboot virtualu servername,,,:/home/servername-reboot:/home/servername-reboot/servername-reboot

...prostě chci mít lepší kontrolu nad bezpečností pokud někoho nechávám přihlásit s uid 0 (resp. chci mít jistotu, že se nedostane do shellu).

Pokud mi v tom někde najdete nějakou bezpečnostní díru, budu jedině rád. Jinak pochopitelně v kombinaci s těmi ncurses - pochopitelně, taky přímo v céčku - z toho chci udělat plnou ovládací konzoli (min. 4 možnosti - shutdown, restart, konzole i tvrdý restart - a klienti se dožadují i možnosti mountování iso image a reinstalace systému z něj... což bude tedy asi oříšek, ale skripty pro XEN toto zahrnují tak jako tak...)

Z toho vyplývá logický dotaz: jsou ncurses tak bezpečné, aby je v tomto režimu (kdy z nich nejde vyskočit do shellu, který danný uživatel ani nemá povolené) bylo možné pustit pro kohokoliv s uid 0 ? a napadá vás jiný způsob, jak toto řešit?

(tady vidíte, že občas přeci jen řeším v C praktické otázky, např. otázk bezpečnosti pod Linuxem - a nepoužívám ho jen pro samoúčelná intelektuální cvičení...)

Vzhledem k tomu, jak nebetyčně chytří je určitá část účastníků tohohle klubu, tak očekávám nějaký geniální nápad, jak se tomuto vyhnout (třeba koupit si hotové komerční řešení nebo doinstalovat balíček, který toto umí a je pro XEN už hotový, apod. :-)