gentoo-hardened vs glibc para

Gentoo

Sziasztok

Van egy kellemes gentoo-hardened rendszerem, és a legutóbbi frissítés után (2.5-r3 glibc +hardened +nptl +nptlonly) elhalálozott az OpenLDAP. Downgrade / BDB / SASL újraforgatás, minden megvolt...

A szerver elindul rendjén, de az első kapcsolódásnál meghal. A debugban csak egy 'Killed' üzenet jelenik meg, strace-szel megnézve a kicsit bőbeszédűbb 'SIGKILL received' tűnik fel. BDB recover és társait próbáltam, nem segített.

A gyanú így a glibc-re terelődött, vagyis a hardened patchelt változatára. Épp most folyik az újraforgatás, de kíváncsi vagyok hátha van valami ötletetek, tapasztalatotok hogy mi okozhatja a parám :)

Frissítve:
a glibc lesz a bűnös, mégpedig valahol a szálkezelés környékén. a hálózatot használó többszálú processzek mind random elhalnak (sshd, openldap, mysql, ...)

Frissítve (2007.06.21)
az új glibc-vel újraforgattam mindent, és openldap megjavult, viszont most az openSSH produkálja ugyanazt a szálkezelési hibát!

--
hege

  • 1467 megtekintés

( ScOut3R | 2007. 06. 16., szo – 19:34 )

Sajnos nem tudok segíteni a problémában, de egy kérdésem lenne.
A hardened ágban mióta van 2.5-ös glibc? Kb. másfél hónapja néztem és akkor még csak 2.3.x volt.

( Hunger | 2007. 06. 16., szo – 19:54 )

Szia,

syslogban nem látsz grsec/PaX üzenetet ezzel kapcsolatban? Esetleg egy kicsit bővebb strace is jól jönne, mert a sigkill már csak a végeredmény.

nem a grsec killeli el, nincs kernel logban erre vonatkozó üzenet.

itt az strace vége, a legbelsőbb elhaló gyerekprocesszel: 


child_stack=0x37a7f4c4, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|
CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID, parent_tidptr=0x37a7fbd8, 
{entry_number:6, base_addr:0x37a7fb90, limit:1048575, seg_32bit:1, contents:0, 
read_exec_only:0, limit_in_pages:1, seg_not_present:0, useable:1}, 
child_tidptr=0x37a7fbd8) = 11694
[pid 19145] futex(0x37a7fbd8, FUTEX_WAIT, 11694, NULL <unfinished ...>
[pid 11694] sendto(933755872, ptrace: umoven: Input/output error
0xc, 1277361828, 0, ptrace: umoven: Input/output error
{...}, 933754056) = 0
[pid 11694] epoll_ctl(6, EPOLL_CTL_ADD, 4, {EPOLLIN, {u32=293003816, u64=293003816}}) = 0
[pid 19145] <... futex resumed> )       = -1 EINTR (Interrupted system call)
[pid 11694] +++ killed by SIGKILL +++
PANIC: handle_group_exit: 11694 leader 19145
Process 11694 detached
+++ killed by SIGKILL +++
Process 19145 detached

még lehet hogy az nptl kavar be, a friss glibc már linuxthreads támogatással fordul... na, ilyenkor jön elő a gentoo-hátrány: már mióta fordul az a szerencsétlen glibc :)

de az eddig működő 2.4-es glibc is csak nptl támogatással volt, és semmi probléma nem jelentkezett...

--
hege

nptl-lel lesz probléma. nptlonly nélkül meg kéne próbálni (minimum a glibc és az openldap újraforgazása mellett).

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

megtörtént ez is, továbbra is a topicnyitóban említett problémát produkálja

# eix glibc
[I] sys-libs/glibc
Available versions: (2.2) 2.2.5-r10 2.3.2-r12 2.3.5-r3 2.3.6-r4 2.3.6-r5 [M]2.4-r4 2.5-r2 2.5-r3 **2.6
Installed versions: 2.5-r3(2.2)(08:34:22 PM 06/16/2007)(-build -debug -glibc-compat20 -glibc-omitfp -hardened -multilib nls nptl -nptlonly -profile -selinux)
Homepage: http://www.gnu.org/software/libc/libc.html
Description: GNU libc6 (also called glibc2) C library

# eix openldap
[I] net-nds/openldap
Available versions: 2.2.28-r7 2.3.30-r2 ~2.3.34-r1 ~2.3.35 2.3.35-r1
Installed versions: 2.3.35-r1(10:12:26 PM 06/16/2007)(berkdb crypt debug -gdbm -ipv6 -kerberos -minimal -odbc -overlays -perl readline samba sasl -selinux -slp -smbkrb5passwd -ssl -tcpd)
Homepage: http://www.OpenLDAP.org/
Description: LDAP suite of application and development tools

--
hege

( hege | 2007. 06. 16., szo – 21:17 )

still no success.

mezei glibc linuxthreads + nptl támogatás + újrapörgettett openldap, és ugyanaz a probléma :s

--
hege

megvolt revdep-rebuild is, nem segített

közben eltüntettem a tcp_wrappers -t is, ugyanis néha az ssh kapcsolat is megszakadt és ez a csomag frissült mostanában, valamint slapd és sshd-val is össze volt linkelve...

de még mindíg ugyanaz a válasz

--
hege

Openldap-ot nem futtatok, de a mysql-lel nincs probléma. Azóta sem, hogy a hardened (pie-ssp) alatt stabil lett a 2.5-ös glibc. Ugyanakkor én az nptlonly-t nem mertem bevállalni. Régebben reportoltak gondokat nptlonly-val hardened alatt. Ezért sincs benn a USE flag-ek között.
Könnyen lehet, hogy a hardened vs nptlonly probléma. Szerintem próbáld meg a hardened levlistát, hátha valaki tud segíteni. Nincs reportolva ilyen bug.

Üdv,
Dw.

"Jegyezze fel a vádhoz - utasította Metcalf őrnagy a tizedest, aki tudott gyorsírni. - Tiszteletlenül beszélt a feljebbvalójával, amikor nem pofázott közbe."

Az eredmény: csak linuxthreads-támogatással újraforgatott glibc + újraforgatott bdb/openldap után működik.

Elképzelhető hogy menne nptl támogatással is, de most már nincs kedvem újrakezdeni, inkább ebédelek meg lefojtok egy sört :)

A tanulságokat megpróbálom megvitatni gentoo-hardened levelezőlistán.

--
hege

Szivesen mennek reszletekbe, de mar nem nagyon emlekszek: tobb honapja volt, hogy (nem sajat linuxon ofkoz) viccbol elkezdtem vele szopni kicsit (sirt szegeny egy - tokeletesen mukodo - app miatt, hogy nem NPTL-es libc, holott amugy de, ott fordult), es amikor elkezdtem megcsinalni amit akart, szethalt egy rakas service random hibakkal. Ja es az atomstabil enterspajz xen miatt volt az egesz reszben.

Azota inkabb hagyom, neha belepityeredik syslogba kicsit, hetente 1x lefagy a teljes userland, olyankor rebootoljak, engem egyik problema se izgat.

Gondolom osszerakod te is a kettot, forditasz 1-2 appot, es latni fogod :) best of luck

eddig nekem sem volt parám glibc-vel, pedig nptlonly egészen egy héttel ezelőttig. para nem volt egy alkalmazással sem (pedig volt 30-as load is néhanapján egy-két véletlen végtelenciklusos lekérdezés miatt). egy újrakonfigolás miatt most indítottam újra slapd-t és hasalt el minden.

nem hitkérdés ezért megy tovább friss glibc linuxthreads-szel, reboot nélkül. (egyenlőre újabb 4 órája hiba nélkül az eddigi ~250 nap után, kopp-kopp)

fogalmazzunk úgy hogy glibc kritikus része a userlandnek :p
úgyhogy: terroristák, csak óvatosan a frissítésekkel!

--
hege

( ScOut3R | 2007. 06. 17., v – 23:06 )

Most nézem, hogy a gcc maradt 3.4.6-os.

Szerintetek ha egy nem hardened rendszeren beállítom a hardened profilt, módosítom a useflageket, átforgatom 4.1.2-es gcc-vel a glibc-t hardenedre, majd a hardened glibc mellé lefordítom a 3.4.6-os gcc-t, majd a 3.4.6-os gccvel újraforgatom a glibc-t, majd ismét a 3.4.6-os gcc-t és úgy újraforgatom a world-ot, működőképes lesz? Huh, ez elég zavarosra sikeredett. Szóval a lényeg, hogy a world forgatásnálán már hardened 3.4.6-tal forgatott glibc és gcc lesz.

( hege | 2007. 06. 21., cs – 14:26 )

új fejlemények:

"minden" megy stabilan, KIVÉVE az openSSH. most ez az állat mutatja ugyanazt a tüneteket mint az openldap tette. Kb néhány mb adatmennyiség átvitele után a kiszolgáló szál SIGKILL-t kap, és bezár a kapcsolat.

pedig minden megvolt (emerge -e world; revdep-rebuild)

áááááá

--
hege

( Replaced | 2007. 06. 21., cs – 15:20 )

kerdes: milyen okokbol kifolyolag upgradelted? volt valami ismert hiba a regiben, amit maskeppen nem tudtal javitani? vagy felteltlenul szukseges uj funkcio?

--
Those who do not understand Unix are condemned to reinvent it, poorly