541
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 25. 04. 2011, 00:42:13 »Našel jsem akorát BSD closeform(2), škoda, že to není na linuxu.closefrom(2)
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
542
Vývoj / Re: Uzavření descriptorů po forku
« kdy: 25. 04. 2011, 00:39:10 »
No díky za nasměrování. Ale portable cesta neexistuje, což mě lehce šokuje. Přitom souhlasím s tím, proč to openssh dělá, je to celkem velké bezpečnostní riziko.
Implementačně se komplikuje i to procházení /proc. Nejsem si jist, jestli to lze bezpečně dělat při vforku. Je to přeci jen nějaká alokace uvnitř parent procesu, přestože se po zavření adresáře paměť uvolní... Jedna z možností je připravit si seznam deskriptorů ještě před vforkem.
Jenže /proc není vždy dostupný, například u chrootu. Pak mi nezbývá než zavírat na slepo. Dělám to metodou počítání hustoty čísel otevřených fd. Pokud při hromadném zavírání nenarazím na otevřený deskriptor po 100 cyklech, tak už dál nehledam, protože je málo pravděpodobné, že by tak velká díra vůbec mohla existovat... ale pořád to možné je.
Našel jsem akorát BSD closeform(2), škoda, že to není na linuxu.
Implementačně se komplikuje i to procházení /proc. Nejsem si jist, jestli to lze bezpečně dělat při vforku. Je to přeci jen nějaká alokace uvnitř parent procesu, přestože se po zavření adresáře paměť uvolní... Jedna z možností je připravit si seznam deskriptorů ještě před vforkem.
Jenže /proc není vždy dostupný, například u chrootu. Pak mi nezbývá než zavírat na slepo. Dělám to metodou počítání hustoty čísel otevřených fd. Pokud při hromadném zavírání nenarazím na otevřený deskriptor po 100 cyklech, tak už dál nehledam, protože je málo pravděpodobné, že by tak velká díra vůbec mohla existovat... ale pořád to možné je.
Našel jsem akorát BSD closeform(2), škoda, že to není na linuxu.
543
Vývoj / Uzavření descriptorů po forku
« kdy: 24. 04. 2011, 23:27:41 »
Zdar. Řeším tu jeden problém se spouštění apikací vfork + execve. Mám docela problém s automatickým sdílením deskriptorů po této velké dvojici.
Píšu si objekt pro manipulaci se spuštěným procesy, což mimojiné umí třeba různé způsoby vytváření rour předtím, než jsou procesy spuštěny. Rád bych po spuštění procesů, aby jediné, co se nasdílí mezi procesy byly deskriptory 0,1,2 a všechno ostatní se zavřelo. Přitom nemohu spolehat na O_CLOEXEC, jednak nemám jistotu, že to programátoři budou všude používat a jednak některé tyhle techniky jsou zavedeny až od jádra 2.6.23 a mývám problémy s distribucemi, kde jsou jádra starší.
Tak mě napadlo, že bych všechny deskriptory zavřel po forku ručně, pomocí smyčky přes všechny a zavolání close(). Ale jak zjistit jejich seznam? Stačilo by, kdybych věděl číslo největšího deskriptoru. Napadá někoho jiné řešení?
PS použil jsem google, a neuspěl jsem
Píšu si objekt pro manipulaci se spuštěným procesy, což mimojiné umí třeba různé způsoby vytváření rour předtím, než jsou procesy spuštěny. Rád bych po spuštění procesů, aby jediné, co se nasdílí mezi procesy byly deskriptory 0,1,2 a všechno ostatní se zavřelo. Přitom nemohu spolehat na O_CLOEXEC, jednak nemám jistotu, že to programátoři budou všude používat a jednak některé tyhle techniky jsou zavedeny až od jádra 2.6.23 a mývám problémy s distribucemi, kde jsou jádra starší.
Tak mě napadlo, že bych všechny deskriptory zavřel po forku ručně, pomocí smyčky přes všechny a zavolání close(). Ale jak zjistit jejich seznam? Stačilo by, kdybych věděl číslo největšího deskriptoru. Napadá někoho jiné řešení?
PS použil jsem google, a neuspěl jsem
544
Vývoj / Re: Spuštění jiného programu z C
« kdy: 23. 04. 2011, 20:06:00 »
Taková kaciířská myšlenka. Lze v handleru SIGCHLD zavolat waitpid z WNOHANG? To abych se rovnou dozvěděl, které dítě umřelo.
545
Vývoj / Re: Spuštění jiného programu z C
« kdy: 22. 04. 2011, 15:57:21 »
No zrovna teď řeším podobný task. Moje knihovna je založená na posílání různých notifikací při nastalé události. Umím podchytit události typu odemčení semaforu, otevření gate, uvolnění zámku, vykonání operace v jiném vláknu, dokonce i příchod dat na otevření socket. Zatoužil jsem po podobném rozhraní u ukončování procesů. Je tu několik zádrhelů.
Proces spustím normálně vfork + execve ovšem v libovolném vlákně, kde to potřebuji. V tom samém vlákně mohu udělat maximálně waitpid (na rozhraní vyvedeno jako join(), aby to bylo podobné jako u threadů). Thready umí mimojiné při ukončení obeslat listenery a na nich zavolat metodu wakeUp. U Procesu to bude horší, nicméně napadlo mě na to vyčlenit vlákno. Nechce se mi ale vyčlenit vlákno per process, ani se mi nechce vytvářet vlákno v případě, že to není potřeba (volající nebude registrovat listenery). Napadlo mě to udělat tak, jak to mám u soketů, že si soket zaregistruju na globální kolektor, který spustí vlákno a ve vlákně provádí select. Jenže u procesů to není tak jednoduché. Jednak mě docela děsí to, že nemohu selektivně čekat na děti. Mohu čekat jen na všechny, nebo na jedno. Další problém je, že na děti budu čekat v jiném vlákně, než vznikly. A třetí zádrhel je, co udělá linux, když čekatelů na děti bude náhodou víc, třeba když jeden bude čekat na všechny děti a druhý bude čekat jen na jedno selektivně.
Proces spustím normálně vfork + execve ovšem v libovolném vlákně, kde to potřebuji. V tom samém vlákně mohu udělat maximálně waitpid (na rozhraní vyvedeno jako join(), aby to bylo podobné jako u threadů). Thready umí mimojiné při ukončení obeslat listenery a na nich zavolat metodu wakeUp. U Procesu to bude horší, nicméně napadlo mě na to vyčlenit vlákno. Nechce se mi ale vyčlenit vlákno per process, ani se mi nechce vytvářet vlákno v případě, že to není potřeba (volající nebude registrovat listenery). Napadlo mě to udělat tak, jak to mám u soketů, že si soket zaregistruju na globální kolektor, který spustí vlákno a ve vlákně provádí select. Jenže u procesů to není tak jednoduché. Jednak mě docela děsí to, že nemohu selektivně čekat na děti. Mohu čekat jen na všechny, nebo na jedno. Další problém je, že na děti budu čekat v jiném vlákně, než vznikly. A třetí zádrhel je, co udělá linux, když čekatelů na děti bude náhodou víc, třeba když jeden bude čekat na všechny děti a druhý bude čekat jen na jedno selektivně.
546
Vývoj / Re: Spuštění jiného programu z C
« kdy: 21. 04. 2011, 16:16:06 »
Holt si microsoft mysli, ze jen jeho zpusob je jediny spravny. Ono se to pozna snadno podle toho, kdo od koho kopiruje. Linux se postupne naucil vlakna, zatimco Windowse nikdo nenaucil forkovat (PS: cygwin to nejak emuluje, a ve WIndows 7 existuje nejake linuxove api, ktere to snad zvladne)
Jinak CreateProcess je userspacova zalezitost, kde je par kernel volani typu "zaloz prazdny proces", "Namapuj pamet noveho procesu do aktualniho" po kterem nasleduje natazeni image do pameti, relokace, natazeni DLL knihoven a konci to zase kernelovskym vytvorenim vlakna v procesu. Jenze jsem nevidel funkcni API kde by se daly tyto kroky volat separatne. Navic se to od verze meni
Jinak CreateProcess je userspacova zalezitost, kde je par kernel volani typu "zaloz prazdny proces", "Namapuj pamet noveho procesu do aktualniho" po kterem nasleduje natazeni image do pameti, relokace, natazeni DLL knihoven a konci to zase kernelovskym vytvorenim vlakna v procesu. Jenze jsem nevidel funkcni API kde by se daly tyto kroky volat separatne. Navic se to od verze meni
547
Vývoj / Re: Spuštění jiného programu z C
« kdy: 21. 04. 2011, 11:46:46 »ondra: jo, jo - linuxovej přístup vypadá na první pohled "hrozně nebezpečně", ale programuje se daleko líp. Windowsí create process je "allinone" bast.
On Microsoft nikdy nechtěl moc forkovat, Windowsy to dodnes neumí, větší tíha byla na vlákna. Možná se tím zase nějaké věci zjednodušují :-)
548
Vývoj / Re: Spuštění jiného programu z C
« kdy: 21. 04. 2011, 09:20:58 »
Fork nevytvari kopii, ale proces nasdili a kopie vznika az za behu, tak jak se meni obsah pameti v kazdem z obou procesu, rika se tomu copy on write a je to jedna ze zakladnich sluzeb strankovani za podpory procesoru. I tak je pravdou, ze se tam nejakymi prostredky plytva zbytecne, ale neni to tak hrozny, jak to na prvni pohled vypada. Proto vznikl vfork (virtual fork), ten funguje podobne ale u neho se predpoklada, ze vzdycky skonci execem. Vznikly child zastavi parenta, docasne prevezme vsechny prostredky parenta aby mohl provest treba nastaveni rour, signalu, zavreni ci otevreni deskriptoru, no a po zavolani exec se parent ze uvolni s tim, ze pokracuje tam kde prestal. vfork je rychlejsi, ale neni to skutecny fork, jen takovy fake.
Mimochodem, Windows nema tento mechanismus a ruzne akce provadene mezi (v)forkem a execem se tam musi resit jinak, treba sdilenim handlu (descriptoru) a s tim spojene problemy typu "kdo nese zodpovednost za uzavreni handlu". Paradoxne ve Windows se kvuli procesu vyplati poustet vlakno, ktery proces sleduje a po jeho skonceni uzavre vsechna sdilena handle. Atd.
Mimochodem, Windows nema tento mechanismus a ruzne akce provadene mezi (v)forkem a execem se tam musi resit jinak, treba sdilenim handlu (descriptoru) a s tim spojene problemy typu "kdo nese zodpovednost za uzavreni handlu". Paradoxne ve Windows se kvuli procesu vyplati poustet vlakno, ktery proces sleduje a po jeho skonceni uzavre vsechna sdilena handle. Atd.
549
Vývoj / Re: Spuštění jiného programu z C
« kdy: 20. 04. 2011, 09:55:15 »
V linuxu fork a ve vytvorenem diteti exec. Tam kde funguje vfork tak pouzit ten, protoze fork muze selhat pokud aplikace ma zaalokovano vic nez polovinu volne pameti * povoleny overcommit.
Ve windows CreateProcess a nezapomenout pozavirat vsechna vytvorena HANDLE.
Pokud chcete sledovat zda proces bezi, pak v linuxu nejaka varianta funkce wait(), ve Windows funkce WaitForSingleObject pro jeden z vytvorenych HANDLE, ktere si samozrejme zavrete az po tom, co proces skonci.
Ve windows CreateProcess a nezapomenout pozavirat vsechna vytvorena HANDLE.
Pokud chcete sledovat zda proces bezi, pak v linuxu nejaka varianta funkce wait(), ve Windows funkce WaitForSingleObject pro jeden z vytvorenych HANDLE, ktere si samozrejme zavrete az po tom, co proces skonci.
550
Odkladiště / Re: bezpečnost asymetrického šifrování
« kdy: 12. 04. 2011, 13:48:46 »
Já myslím, že hlavní problém tazatele je ten, že obrátil logiku v tom smyslu, jakym klíčem jaká data šifruju. Zpravidla totiž šifruji data, veřejným klíčem toho, komu ty data posílám. Nikoliv, že bych já posílal data zašifrovaná mým klíčem, protože ty si může samozřejmě kdokoliv veřejně rozšifrovat veřejným klíčem (nemohu šifrovat veřejným klíčem, protože ty si zase nikdo nepřečte).
Nicméně, šifrování mým privátním klíčem určitý smysl má, tím mohu ověřit, že zpráva je opravdu zašifrovaná konkrétním privátním klíčem. Pak pouze veřejným klíčem odesílatele mohu zprávu dešifrovat a tím ověřit pravost odesílatele.
Takže rekap.
- Chci zabránit přečtení zprávy. Šifruji veřejným klíčem toho, komu zprávu posílám
- Chci zabránit změně odesílatele zprávy. Šifruji svým privátním klíčem a každý si může ověřit dešifrováním pomocí mého veřejného klíče, že zpráva je skutečně odemě.
Nicméně, šifrování mým privátním klíčem určitý smysl má, tím mohu ověřit, že zpráva je opravdu zašifrovaná konkrétním privátním klíčem. Pak pouze veřejným klíčem odesílatele mohu zprávu dešifrovat a tím ověřit pravost odesílatele.
Takže rekap.
- Chci zabránit přečtení zprávy. Šifruji veřejným klíčem toho, komu zprávu posílám
- Chci zabránit změně odesílatele zprávy. Šifruji svým privátním klíčem a každý si může ověřit dešifrováním pomocí mého veřejného klíče, že zpráva je skutečně odemě.
551
Vývoj / Re: C++, ukazatel na statickou funkci
« kdy: 08. 04. 2011, 07:32:59 »
No ja to nevyuziju, protoze mam kontejnery navrzene trochu jinak, vic javovsky
V Jave se to pouziva spis ve while cyklu. Podstatnou vyhodou tohodle stylu je, ze kiteraci mi staci jen jeden objekt (neni treba vytahovat dva nebo nekdy dokonce tri!). Iterator se chova jako stream a tak neni rozdil, zda ten kdo data cte je vytahuje z kontejneru, nebo jsou za behu generovany. Takove "pythonovske" generatory jsou v tom naprosto super.
Kód: [Vybrat]
for (auto i = pole.getFwIter();i.hasItems();) {
auto x = i.getNext();
...
}
V Jave se to pouziva spis ve while cyklu. Podstatnou vyhodou tohodle stylu je, ze kiteraci mi staci jen jeden objekt (neni treba vytahovat dva nebo nekdy dokonce tri!). Iterator se chova jako stream a tak neni rozdil, zda ten kdo data cte je vytahuje z kontejneru, nebo jsou za behu generovany. Takove "pythonovske" generatory jsou v tom naprosto super.
552
Vývoj / Re: Nastavení Java heapu na Mac OS
« kdy: 07. 04. 2011, 21:49:08 »kedze mac osx je viacmenej BSD, tipujem ze toto by mohlo fungovat:
http://serverfault.com/questions/56667/how-can-i-tell-how-much-ram-is-installed-on-a-freebsd-server
- sysctl hw.physmem
- grep memory /var/run/dmesg.boot
Dík, to už zní líp. Bohužel, nemám k dispozici Macka pernamentně a v tom krátkém sezení už to musím mít připravený. Zabalit java aplikaci do App adresáře jsem ještě zvládl podle internetu, tohle bude vyžadovat víc. Uživatele samozřejmě zajímá jen ta finální aplikace.
553
Vývoj / Re: Agilné programovanie v praxi
« kdy: 07. 04. 2011, 21:13:09 »
Vývoj používá scrum, webmasteři u nás jedou v kanbanu.
554
Vývoj / Re: Nastavení java-heapu na Mac OS
« kdy: 07. 04. 2011, 21:08:22 »$ java -XA co tam napsat, aby to java pochopila jako 1/2 instalované paměti?
...
-Xms<size> set initial Java heap size
-Xmx<size> set maximum Java heap size
...
555
Vývoj / Nastavení Java heapu na Mac OS
« kdy: 07. 04. 2011, 12:05:45 »
Zdar.
Dělám deploy java aplikace na Macovi, protože to vyžaduje zákazník. Já mám Maca jen na testování, jinak to není moje primární ani sekundární platforma. Potřeboval bych nějakým způsobem umět nastavit heap javovské aplikace tak, aby zabral určitou část dostupné paměti. Na Windows mám launcher, který tomu nastaví polovinu instalované paměti.
Na Mac OS jsem to zabalil podle návodu do složky jmeno.app a v tom je soubor Info.plist, kde mohu definovat parametr -Xmx, ale pouze natvrdo. Zatím to řešíme tak, že downloadovací stránka se ptá uživatele, kolik má paměti a podle toho vybere patřičný balíček, ale tohle řešení se mi moc nelíbí. Nemá někdo lepší?
(PS: používám JavaApplicationStub)
Dělám deploy java aplikace na Macovi, protože to vyžaduje zákazník. Já mám Maca jen na testování, jinak to není moje primární ani sekundární platforma. Potřeboval bych nějakým způsobem umět nastavit heap javovské aplikace tak, aby zabral určitou část dostupné paměti. Na Windows mám launcher, který tomu nastaví polovinu instalované paměti.
Na Mac OS jsem to zabalil podle návodu do složky jmeno.app a v tom je soubor Info.plist, kde mohu definovat parametr -Xmx, ale pouze natvrdo. Zatím to řešíme tak, že downloadovací stránka se ptá uživatele, kolik má paměti a podle toho vybere patřičný balíček, ale tohle řešení se mi moc nelíbí. Nemá někdo lepší?
(PS: používám JavaApplicationStub)
