1157502393 Q * lilalinux_ Remote host closed the connection 1157505128 Q * olilo Ping timeout: 480 seconds 1157505679 J * olilo hiddenserv@tor.noreply.org 1157507494 M * Bertl hmm ... interesting: 1157507542 M * Bertl "Our overhead is lower than Xen too -- it's about two or three percent." -- Kir Kolyshkin (talking about OpenVZ on techworld.com :) 1157510594 J * Aiken_ ~james@tooax6-020.dialup.optusnet.com.au 1157510922 Q * Aiken Ping timeout: 480 seconds 1157511715 Q * FloodServ helium.oftc.net services.oftc.net 1157512074 J * FloodServ services@services.oftc.net 1157512962 Q * hvd Ping timeout: 480 seconds 1157514467 Q * FireEgl Read error: Connection reset by peer 1157514900 J * FireEgl FireEgl@Sebastian.Atlantica.US 1157515350 Q * Loki|muh Remote host closed the connection 1157515372 J * Loki|muh loki@satanix.de 1157516905 Q * olilo Remote host closed the connection 1157516924 J * lolilol hiddenserv@tor.noreply.org 1157521286 Q * id23 Ping timeout: 480 seconds 1157521806 J * id23 ~id@p50812671.dip0.t-ipconnect.de 1157523030 M * Bertl okay, off to bed now .. have a good one everyone! cya tomorrow! 1157523036 N * Bertl Bertl_zZ 1157523215 Q * cdrx Ping timeout: 480 seconds 1157523466 J * meandtheshell ~markus@85-124-233-117.work.xdsl-line.inode.at 1157526675 J * cdrx ~legoater@242.32.96-84.rev.gaoland.net 1157526786 Q * cdrx 1157527291 J * prae ~Benjamin@5-63.206-83.static-ip.oleane.fr 1157527398 J * ||Cobra|| ~cob@pc-csa01.science.uva.nl 1157527510 J * dna ~naucki@78-226-dsl.kielnet.net 1157527902 Q * Aiken_ Ping timeout: 480 seconds 1157528885 J * dlezcano ~dlezcano@AToulouse-252-1-89-182.w86-201.abo.wanadoo.fr 1157528909 M * dlezcano hi all 1157529197 M * ruskie hmm I wonder if there's a way to check capabilites from a shell script... 1157529756 J * Hollow_mobile ~bene@p5497B460.dip0.t-ipconnect.de 1157529770 M * Hollow_mobile morning folks 1157529825 M * ruskie lo 1157529827 J * cdrx ~legoater@242.32.96-84.rev.gaoland.net 1157530606 J * lilalinux ~plasma@dslb-084-058-196-163.pools.arcor-ip.net 1157532728 J * Hmmmm ~Hmmmm@221.135.51.19 1157532785 Q * MrX Ping timeout: 480 seconds 1157533185 M * Hmmmm hi anyone there? 1157533265 M * nayco Hello, all ! 1157533303 M * nayco Hollow_mobile: http://linuxfr.org/2006/09/06/21291.html (not to long to moderate) 1157533332 M * Hmmmm hi, i want to change the date in a vserver. can't figure out how to do that 1157533447 J * shedii ~siggi@inferno.lhi.is 1157533466 M * nayco Hmmmm: I don't know if you can, if fact. 1157533492 M * Hmmmm nayco: that's what I'm trying to figure out 1157533501 M * nayco What you should do is : 1157533505 M * Hmmmm any idea if there's a work around? 1157533514 M * nayco 1) setup NTPd in the host server 1157533548 M * Hmmmm ok 1157533565 M * nayco 2) cp /usr/share/zoneinfo/xxxx/yyyy /etc/localtime inside the vserver. 1157533566 J * s4edi ~siggi@inferno.lhi.is 1157533585 M * nayco this way, all vservers have the right time, but the zone can be different 1157533602 M * nayco ...for each vserver 1157533616 M * Hmmmm but then i cant set that date to something like 100 days before, or can i? 1157533678 M * nayco Hmmmm: no, all the vservers will have the _same_ date (+/-12 hours if you change /etc/localtime) 1157533704 M * Hmmmm but the kind of limitation I want to overcome 1157533715 Q * shedi Ping timeout: 480 seconds 1157533722 M * Hmmmm my develloper needs to set a date something like 100 days ago 1157533739 M * nayco And in fact I don't even think you can change the system date from inside the vservers, without giving them capabilities 1157533750 M * Hmmmm ah ic 1157533761 M * Hmmmm so i shud just tell him its not possible for now 1157533771 M * Hmmmm http://deb.riseup.net/vserver/old-stuff/notes/ 1157533786 M * nayco What you can do, instead, is NOT using NTPd in the host, then set whatever date you want, and then all the vservers will have the same date ! 1157533794 M * Hmmmm this page says that:"CAP_SYS_TIME - You are allowed to set time: date, netdate, xntpd" is yet to be implemented 1157533905 M * nayco Maybe cap_sys_time works now, but even if you can set any date you want, remember that the date will be the same for all vservers. 1157533916 M * nayco Well, not sure, but nearly ;-) 1157533924 M * Hmmmm nayco: ic. I guess we'll just have to make do 1157533940 Q * shedii Ping timeout: 480 seconds 1157533976 M * Hmmmm thanks a lot 1157534036 P * Hmmmm Ex-Chat 1157534300 Q * s4edi Ping timeout: 480 seconds 1157534528 Q * Hollow_mobile Quit: This computer has gone to sleep 1157535235 Q * matti Ping timeout: 480 seconds 1157535604 J * matti matti@linux.gentoo.pl 1157535829 M * matti Hello? ; 1157535830 J * glut glut@no.suid.pl 1157535832 Q * prae Ping timeout: 480 seconds 1157535837 M * matti Anybody out there? :) 1157535837 M * matti ;p 1157535904 M * ruskie lo 1157535939 M * matti :) 1157535949 M * matti I have some fanny issue :-) 1157535962 M * matti I presume, that this is releated to grsecurity, but... 1157535974 M * matti In host: 1157536028 M * matti http://romke.net/paste/dZ9F 1157536034 M * matti And then in guest: 1157536046 M * matti http://romke.net/paste/e1UF 1157536047 M * matti :) 1157536070 M * matti The question is: why I do not see any named there? :) 1157536081 M * matti I assume, that named from ns2 was taken by aliens :) 1157536240 M * matti Restriction on "dobule chroots" is not set in grsecurity, and named is chrooted within guest to /chroot/dns (default in Gentoo). 1157536447 J * prae ~Benjamin@5-63.206-83.static-ip.oleane.fr 1157536534 M * matti LOL 1157536543 M * matti TPB have new theme song ;] 1157536549 M * matti This guy is crazy ;) 1157536551 M * matti http://deadbeef.info/tmp/TPB_theme.mp3 1157536553 M * matti Ahaha. 1157536575 M * matti TPB = The Pirate Bay if somebody didn't know ;p 1157537657 Q * matti Ping timeout: 480 seconds 1157537939 J * matti matti@linux.gentoo.pl 1157538259 M * daniel_hozac matti: hmm, ns1 != ns2? 1157538314 M * matti daniel_hozac: Yes, yes. ns1 is working on other machine. This is my mistake and accidently copied from terminal ;] 1157538335 M * matti s/accidently/accidentally/ 1157538335 M * daniel_hozac so what's the problem? 1157538354 M * daniel_hozac that named isn't running? 1157538361 M * matti Is running. 1157538373 M * matti Is running and working. 1157538375 M * daniel_hozac hmm? 1157538378 M * daniel_hozac not on ns2 though? 1157538385 M * matti On ns2. 1157538385 M * daniel_hozac umm, ns1 i mean. 1157538416 M * matti ns1 was just my mistake, heh. Just a typo. 1157538438 M * daniel_hozac so i guess i just don't get the problem then :) 1157538448 M * matti Ehm. 1157538477 M * matti http://romke.net/paste/dZ9F 1157538497 M * daniel_hozac right... what about it? 1157538505 M * matti http://romke.net/paste/e5IP 1157538544 M * daniel_hozac and that's on the same host? ;) 1157538551 M * matti Yes. 1157538553 M * daniel_hozac that does look very strange... 1157538584 M * matti And as I said. named is working as ns2 fine. 1157538600 M * matti But, wht is not listed in ps aux output in guest namespace? 1157538607 M * matti This is the question ;] 1157538613 M * daniel_hozac a very good one. 1157538630 Q * cdrx Ping timeout: 480 seconds 1157538643 M * matti I try to use lsof, but lsof is not xid aware, so didin't work either ;p 1157538660 M * daniel_hozac chcontext --xid 1 bash 1157538672 M * Loki|muh vlsof would be a nice thing ;) 1157538701 M * daniel_hozac send patches ;) 1157538739 M * matti ;p 1157538741 M * matti Hehe. 1157538743 M * matti Loki|muh: Indeed. 1157538777 M * Loki|muh if I would know enough for that... :( 1157538777 M * daniel_hozac matti: and with that bash, run cat /proc/7671/status 1157538799 M * matti Whops. 1157538854 M * matti http://romke.net/paste/e71F 1157538957 M * daniel_hozac matti: hmm, that's an odd ppid. 1157538978 M * daniel_hozac matti: if you enter the guest, can you run ls -l /proc/7671? does the directory exist 1157539040 M * matti Nope. 1157539432 M * matti http://romke.net/paste/ecaf 1157539468 Q * sladen Ping timeout: 480 seconds 1157539698 M * matti crux ~ # vserver ns2 enter 1157539699 M * matti ns2 / # ls -l proc/ | grep 7671 1157539699 M * matti ns2 / # echo $? 1157539699 M * matti 1 1157539700 M * matti Hm... 1157539721 M * daniel_hozac very strange... 1157539724 M * matti crux ~ # vps aux | grep 13101 1157539725 M * matti root 13101 1086 ns2 0.0 0.0 1484 508 ? Ss 01:32 0:01 init [3] 1157539739 M * matti So, his ppid theoretically exists. 1157539745 M * daniel_hozac IMHO named's vx_info is incorrect. 1157539767 M * daniel_hozac oh right, you got that from xid 1... so yeah, that is correct. 1157539796 M * matti So, vx_info is broken somewhere? 1157539806 M * daniel_hozac well, maybe not. 1157539810 J * sladen paul@starsky.19inch.net 1157539818 M * daniel_hozac so what grsec patch do you use? 1157539869 M * matti daniel_hozac: The one from harry. But I never had such problems/issues. Or I didn't noticed any before. 1157540047 M * daniel_hozac matti: can you kill -0 7671? 1157540054 M * daniel_hozac from inside the guest, that is. 1157540066 M * prae You know that who is responsible to make official patch for vs+grsec now ? 1157540069 M * matti From xid 1 or in ns2 namespace? 1157540086 M * matti prae: There's no official patch. 1157540110 M * matti prae: And there never will be :) 1157540118 M * prae "The latest version of the stable Linux-VServer + grsecurity patch is: 2.6.17.11 vs2.0.2-grsec2.1.9 ChangeLog" :-\ 1157540150 M * daniel_hozac harry. 1157540151 M * prae hosted under kernel.org and harry's homepage 1157540170 M * prae okay 1157540173 M * matti prae: So, you got your answer. But this patches are only harry's contribution. 1157540178 M * daniel_hozac kernel.org? i thought he put it on people.linux-vserver.org 1157540191 M * prae daniel_hozac: sorry, mistake 1157540195 M * prae not kernel.org ;) 1157540203 M * matti ;-p 1157540283 M * matti daniel_hozac: Kill from xid 1 or ns2? 1157540304 M * matti Oh well. 1157540305 M * matti ns2 / # kill -0 7671 1157540305 M * matti bash: kill: (7671) - No such process 1157540331 M * daniel_hozac so something is very wrong... 1157540403 M * prae I'm happy to see that :) making vs+grsec patch took to me too time (when i make it ... a long time ago :) 1157540444 M * harry daniel_hozac: ? 1157540469 M * matti Hi harry :) 1157540481 M * prae Hi harry 1157540486 M * harry haha... its people.linux-vserver.org indeed 1157540488 M * harry not kernel.org 1157540503 M * harry would be nice to see this all in the standard kernel tough...but impossible :0 1157540512 M * matti harry: Somethings is broken in patch. 1157540515 M * prae *dream* :) 1157540515 M * daniel_hozac harry: see matti's pastes. 1157540537 M * daniel_hozac harry: the process is supposedly inside the context, but the context can't see it ;) 1157540548 M * harry that's not good! 1157540553 M * matti Indeed. 1157540553 M * matti ;] 1157540562 A * harry gotta run now 1157540565 M * matti LOL 1157540567 M * harry but i'll be back in a few hours... 1157540573 J * romke ~romke@acrux.romke.net 1157540575 M * matti harry: k. Take care. 1157540579 M * harry (have to get to work, promised my boss i'd be there in 30 mins... 1157540580 J * independence ~independe@marcusson.no-ip.com 1157540583 M * harry which is 45 mins ago 1157540589 M * harry and i still haven't left yet 1157540589 M * matti harry: Whoops. 1157540591 M * matti harry: Go go. 1157540601 M * independence Is it possible to use chattr in a vserver guest? 1157540616 M * independence The guest system uses a ext3 partition 1157540630 M * daniel_hozac independence: to do what? 1157540656 M * independence I wan't to set the append only flag 1157540676 M * daniel_hozac that might be possible... 1157540926 M * independence Is there something special you have to do to get it to work? Couse it doesn't work for me.. 1157540958 M * doener http://lkml.org/lkml/2006/9/5/246 -- capability system enhancements, might be interesting 1157541028 M * daniel_hozac independence: what error do you get? 1157541035 M * daniel_hozac doener: 64-bit? :) 1157541041 M * independence I could set it from the host system 1157541047 M * matti daniel_hozac: romke just tell me, that named running in foreground mode within ns2 is also hard to kill by ^C (SIGKILL). 1157541052 M * matti daniel_hozac: This is very odd. 1157541101 M * daniel_hozac isn't ^C SIGINT? 1157541101 M * romke matti: I can try runing named in other guest (copy configs) without chrooting, or sth... 1157541116 M * daniel_hozac independence: that's expected. 1157541151 M * daniel_hozac but yes, if the process somehow becomes invisible, killing it would be impossible. 1157541258 M * doener daniel_hozac: 64bit, but not in the way you might expect it ;) 1157541265 M * matti daniel_hozac: Yes, sorry. I am distracted by two annoying people now, and I cannot focus on this as I want to, heh :( 1157541333 J * shedi ~siggi@inferno.lhi.is 1157541386 M * matti romke: k, if you have some time now, then please. 1157541500 M * matti daniel_hozac: grsecurity is involded that is 100% sure. Since, clean vanilla guest works fine. 1157541522 M * matti daniel_hozac: But I cannot say, which part is wrong - the chroot restrictions? Some other code... 1157541538 M * matti daniel_hozac: We probably need to wait for harry or Bertl. 1157541558 M * daniel_hozac i have to admit that i've never even looked at grsec. 1157541592 M * daniel_hozac can you easily reproduce the issue? 1157541613 M * matti daniel_hozac: Maybe. romke is working on some tests right now. 1157541633 M * matti daniel_hozac: We need to give 'em a while now :) 1157541639 M * daniel_hozac ok :) 1157541664 M * matti I am starving... I need to eat something :) 1157541689 M * romke daniel_hozac: restarting guest gives same results, I'll could even try preparing image from guest that behaves this way... 1157541751 M * daniel_hozac that's very interesting. 1157541764 M * daniel_hozac have you tried stracing named to see where it gets out of the context? 1157541820 M * matti He gets out? 1157541840 M * daniel_hozac well, partially at least, as it's no longer controllable from within the context. 1157541842 M * matti xid 1 shows, that he is still runing within ns2 namespace. 1157541856 M * daniel_hozac so something goes wrong there. 1157541879 M * matti daniel_hozac: That's probably because some proc-magic are broken ;] 1157541896 M * daniel_hozac well, that was my initial thought, but then when you couldn't kill it either... 1157541908 M * matti Hm... 1157541910 M * matti Indeed. 1157541961 M * daniel_hozac doener: a capability for executing binaries seems a bit overkill :) 1157541967 M * matti romke: I can recompile kernel w/o chroot restrictions - to see, if this is causing this. 1157541982 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1157541995 M * daniel_hozac doener: if it continues like this, it'll need 128-bit capabilities :) 1157541999 M * matti daniel_hozac: Ehehe, sounds like something for really paranoid people ;] 1157542007 M * doener daniel_hozac: BYTE! not bit ;) 1157542020 M * romke matti: faster will be to try named without chroot 1157542020 M * daniel_hozac lol 1157542063 J * shedii ~siggi@inferno.lhi.is 1157542178 M * matti Hm... 1157542184 M * matti romke: k ;) 1157542300 Q * shedi Ping timeout: 480 seconds 1157543031 Q * romke Quit: guest restart 1157543040 M * harry mkay... /me ready to debug! 1157543138 M * harry hehe... if ^C would be SIGKILL that would be fun! :) 1157543168 M * harry matti: get your bitchass over here, slave! ;) 1157543173 M * harry (moehaha... /me in evil mode :)) 1157543220 M * matti Sir yes sir! 1157543228 M * harry good doggy :) 1157543229 M * matti Would you like some tea? :) 1157543231 M * matti ;p 1157543234 M * harry 5 please :) 1157543238 M * matti Fresh newspaper also? 1157543239 M * matti ;p 1157543250 M * harry naah... fresh toiletpaper would be better... 1157543256 M * Loki|muh lol 1157543258 M * harry don't like the printing of newpapers on my butt 1157543264 M * matti harry: LOL 1157543267 M * matti harry++ 1157543268 M * harry so hard to read :) 1157543279 M * matti Even with mirror ;p I can imagine ;p 1157543283 M * harry anyway... lets troubleshoot! :) 1157543288 M * matti Yoyx. 1157543313 A * harry looks for da paste of the error you have 1157543355 M * matti harry: Start read the channel backlog from 12:28 (GMT+2 time). 1157543372 M * daniel_hozac http://romke.net/paste/e5IP http://romke.net/paste/dZ9F 1157543476 M * harry (telephone) 1157543503 M * matti daniel_hozac: romke just reported, that without chroot everything is visible inside ns2 namespace. 1157543571 M * daniel_hozac ok, so chroot is causing the problem. 1157543586 M * matti So, we have. 1157543601 M * matti Level 1: vserver (chroot more or less). 1157543613 M * matti Level 2: named is chrooted to /chroot/dns. 1157543623 M * matti And the problem shows up. 1157543643 M * daniel_hozac where were your example grsec configuration? 1157543649 M * Hollow doesn't vserver handle the / rbind + chroot in some way? 1157543658 M * Hollow maybe look at that section.. 1157543665 J * Revelator ~Efnet@62.128.240.117 1157543670 M * Hollow if there is grsec code atall 1157543670 M * daniel_hozac it's probably not a vanilla vserver issue. 1157543675 M * Hollow yeah, i read that 1157543680 M * matti Not, not a vanilla. 1157543690 M * Hollow but it might be related to that 1157543711 M * Hollow that grsec somehow cannot/does not handle this special case 1157543714 M * Hollow *shrug* :) 1157543722 M * matti http://romke.net/paste/eewC 1157543756 M * matti The safe options I manage to tests. 1157543768 M * matti All guest are working w/o problems. 1157543778 J * romke ~romke@acrux.romke.net 1157543792 M * matti s/guest/guests/ 1157543844 Q * shedii Quit: Leaving 1157544044 M * matti Maybe the CONFIG_GRKERNSEC_CHROOT_FCHDIR? 1157544054 M * matti But, I am not really sure. 1157544096 M * daniel_hozac do you get anything in the logs on the host? 1157544156 M * matti No. 1157544166 M * daniel_hozac does grsec usually log denials? 1157544172 M * matti Yes. 1157544189 M * matti I enabled most of audit options. 1157544194 M * matti Nothing really shows up. 1157544202 M * matti Releated to this in some way. 1157544243 M * daniel_hozac hmm, did you leave out the vserver specific lines of http://romke.net/paste/e71F? 1157544251 M * matti Nothing. 1157544257 M * matti Some mount notices. 1157544271 M * matti Some other notices on time changes. 1157544295 M * matti daniel_hozac: vserver specific lines? 1157544312 M * daniel_hozac yes, /proc//status should _at_least_ contain the xid of the current process. 1157544324 M * daniel_hozac unless you have info_hide set for that guest. 1157544350 M * daniel_hozac (in which case, vattribute --set --xid --flag ~info_hide should remove it at runtime and you should be able to recat it) 1157544379 M * Hollow seems like we missed the opportunity to have a speech at http://www.linux-magazin.de/virtualization/zeitplan.html *bad pr!* ;) 1157544450 M * daniel_hozac too bad... 1157544482 M * matti daniel_hozac: It seems, that this is default in Gentoo and vserver. I never changed this ;) 1157544527 M * Hollow not that i know of... but brb! 1157544551 M * daniel_hozac matti: i guess you could check /proc//vinfo instead. 1157544596 M * daniel_hozac (but still, disabling info_hide would probably be helpful) 1157544650 M * matti Well, I do not have the vinfo in /proc inside ns2 ;p 1157544753 M * doener that's to be done from the host 1157544765 M * matti Oh. 1157544809 M * daniel_hozac chcontext --xid 1 1157544858 M * matti ls: vinfo: No such file or directory 1157544858 M * matti ls: ninfo: No such file or directory 1157544860 M * matti Hm... 1157544879 M * matti Looks bad? 1157544887 M * daniel_hozac disable info_hide and retry. 1157544940 M * matti crux ~ # vattribute --set --xid 3018 --flag ~info_hide 1157544940 M * matti Unknown flag 'info_hide' 1157544949 M * matti Ops. 1157544957 M * matti Hm... 1157544971 M * daniel_hozac try ^6 instead. 1157544989 M * matti --flag ^6? 1157544998 M * daniel_hozac ~^6, i think... 1157545012 M * matti Worked. 1157545140 M * matti Still ls: vinfo: No such file or directory 1157545141 M * matti ls: ninfo: No such file or directory 1157545144 M * matti Heh. 1157545425 M * daniel_hozac very strange... 1157545784 M * daniel_hozac matti: can you do it for a process that is visible inside the guest? 1157545836 M * matti Yes. 1157545986 M * matti daniel_hozac: This same no such file error. 1157546087 M * daniel_hozac very strange. 1157546094 M * daniel_hozac i'm completely clueless... 1157546101 M * harry wait... named chroots too? 1157546114 M * daniel_hozac yes. 1157546152 Q * id23 Ping timeout: 480 seconds 1157546184 M * harry matti: i suggest you disable chroot restrictions for testing... 1157546187 M * harry see if that helps? 1157546203 M * harry then we know if it's a pax problem or randomization etc.. 1157546213 M * daniel_hozac when named doesn't chroot, it works fine. 1157546227 M * harry so it's a problem with the chroot restrictions in grsec 1157546239 M * harry problem isolated even more! this is going well :) 1157546252 M * matti Heh. 1157546264 M * harry (sry, boss here, 5 telephone calls, other people with X rpoblems... and i have to do this too... it's getting a bit too much here...) 1157546275 M * matti daniel_hozac: I don't know why this {n,v}info is not visible. 1157546295 M * daniel_hozac well, info_hide would cause that. 1157546381 M * harry grmbl... next prob.... brb 1157546720 M * matti daniel_hozac: But, it supposed to be disabled now, right? 1157546726 J * Dead-BY10Trucks ~gfr343@tor-irc.dnsbl.oftc.net 1157546733 P * Dead-BY10Trucks 1157546903 M * daniel_hozac well... yes. what does /proc/virtual//status say for Flags? 1157546925 M * Hollow hm.. CONFIG_PRIVACY? 1157546942 M * daniel_hozac it's stable though... 1157546946 M * Hollow ah, ok 1157546954 M * doener can I get a short summary of the problem? 1157546955 J * XOOM ~XOOM@200.230.80.153 1157546966 J * h01ger ~holger@socket.layer-acht.org 1157546978 M * Hollow ni info_hide and not /proc/self/vinof & friends 1157546986 M * daniel_hozac http://romke.net/paste/e5IP http://romke.net/paste/dZ9F 1157546989 M * Hollow uh.. watch your fingers while typing 1157546999 M * h01ger hi, congrats to the release + the new wiki layout! 1157547005 M * XOOM Hi 1157547007 M * XOOM I am with a problem in my virtual server 1157547013 M * daniel_hozac named isn't visible in the guest. 1157547014 M * Hollow hi h01ger, thanks :) 1157547015 M * h01ger can i run i386 vservers on a amd64 host? 1157547020 M * daniel_hozac h01ger: yes. 1157547023 M * h01ger cool 1157547030 M * XOOM FATAL: Could not load /lib/modules/2.6.14.3-vs2.0.1/modules.dep: No such file or directory 1157547030 M * XOOM iptables v1.2.11: can't initialize iptables table `filter': Permission denied (you must be root) 1157547030 M * XOOM Perhaps iptables or your kernel needs to be upgraded. 1157547040 M * Hollow daniel_hozac: ah i thought we're still investigating missing xid in /proc/self/status? 1157547043 M * Hollow or is it related? 1157547050 M * daniel_hozac Hollow: yep. 1157547061 M * Hollow i see 1157547077 M * daniel_hozac the missing xid was discovered when debugging. 1157547090 M * daniel_hozac http://romke.net/paste/e71F 1157547106 M * XOOM somebody can help me to arrange the error of iptables in the virtual server ? 1157547121 M * Hollow strange that it appears in vps then.. 1157547128 M * daniel_hozac XOOM: you need to setup iptables on the host. 1157547132 M * daniel_hozac Hollow: indeed. 1157547149 M * XOOM what? 1157547158 M * Hollow i guess vps is using get_task_xid? 1157547189 M * daniel_hozac XOOM: a guest cannot setup iptables without giving it enough capabilities to mess with everything else in the network stack. 1157547194 M * daniel_hozac Hollow: yep. 1157547198 M * daniel_hozac Hollow: IIRC, anyway. 1157547204 M * h01ger derjohn, in the wiki you suggest to rebuild util-vservers on sarge. you could also mention www.backports.org, there are backported linux-images (2.6.16) with vserver-patch enabled and a updated util-vserver package as well 1157547214 M * h01ger (i didnt find an edit-button on the faq page..) 1157547250 M * doener h01ger: right at the top ;) 1157547257 M * h01ger wah 1157547268 M * XOOM daniel_hozac: it forgives, I am not understanding.you are saying that she does not have as? 1157547272 M * Hollow h01ger: you need to create an account 1157547286 M * doener Hollow: I'm not logged in either 1157547290 M * Hollow hu? 1157547292 M * Hollow strange 1157547312 M * matti daniel_hozac: 1157547313 M * matti UseCnt: 213 1157547313 M * matti Tasks: 33 1157547313 M * matti Flags: 00000000020a0230 1157547313 M * matti BCaps: 00000000354c24ff 1157547314 M * doener and I get a funny google maps error message when I hit edit 1157547315 M * matti CCaps: 0000000000000101 1157547317 M * Hollow ah, ok.. locked main page... but shouldn't we disable anon edits? 1157547318 M * matti Ticks: 0 1157547322 Q * dna Quit: Verlassend 1157547331 M * Hollow doener: don't use wiki.* 1157547336 M * Hollow just plain linux-vserver.org 1157547358 M * daniel_hozac matti: hmm, that has info_hide set. 1157547358 M * doener Hollow: how about some redirection magic then? ;) 1157547375 M * matti daniel_hozac: I do what you told me :) 1157547395 M * h01ger edited 1157547399 M * derjohn h01ger, yes, pls add ! 1157547400 M * matti daniel_hozac: vattribute --set --xid 3018 --flag ~^6 1157547401 M * Hollow well, there is a lot of redirection magic, we just left wiki.* in case you want to edit a page with the same name as in the old wiki which is not migrated yet (in which case the redirection map will redirect to the old wiki) 1157547404 M * h01ger Hollow, no, i didnt 1157547406 M * daniel_hozac XOOM: guests do not have their own iptables, no. 1157547407 M * h01ger derjohn, ? 1157547415 M * h01ger ah 1157547425 M * derjohn ... you could also mention www.backports.org ... 1157547427 M * derjohn kk ) 1157547431 M * h01ger i did :) 1157547442 M * matti daniel_hozac: Oh, heh, 3018 was restarted by romke. 1157547447 M * daniel_hozac ;) 1157547467 A * h01ger leaves again - ETOOMANYCHANNELS. have fun & thanks for all the fancy fish :) 1157547474 P * h01ger Leaving 1157547519 M * XOOM daniel_hozac: oh my god.....lol....my virtual server this suffering to attacks bruteforce in ssh, needed to twirl one script that he adds rules in iptables to block the IP 1157547539 M * matti daniel_hozac: k, now: 1157547540 M * matti crux 3018 # vattribute --set --xid 3018 --flag ~^6 1157547541 M * matti crux 3018 # cat status 1157547541 M * matti UseCnt: 213 1157547541 M * matti Tasks: 33 1157547543 M * matti Flags: 00000000020a0230 1157547546 M * matti BCaps: 00000000354c24ff 1157547547 M * Hollow doener: http://paste.linux-vserver.org/339 1157547548 M * matti CCaps: 0000000000000101 1157547551 M * matti Ticks: 0 1157547557 M * matti daniel_hozac: Looks, linke nothing changed. 1157547571 M * matti s/linke/like/ 1157547608 M * daniel_hozac matti: strange... try ~^5/7? 1157547640 M * doener I see 1157547666 M * matti daniel_hozac: ~^5 works. 1157547667 M * matti daniel_hozac: Flags: 00000000020a0210 1157547699 M * daniel_hozac matti: oh... ok, thanks :) 1157547716 M * daniel_hozac XOOM: might want to use hosts.deny instead? 1157547823 M * matti daniel_hozac: Ehm, what I really do now? 1157547871 M * daniel_hozac try accessing the vinfo now. 1157547895 M * matti daniel_hozac: Yes, now it is working :) 1157547900 M * daniel_hozac there we go! ;) 1157547915 M * matti ;p 1157547915 M * doener is there any documentation that tells what exactly grsec does/can do for chroots? 1157547961 M * matti doener: Little on grsecurity website. 1157547970 M * matti doener: And some in Kconfig. 1157547982 M * daniel_hozac http://www.grsecurity.net/features.php 1157547984 M * daniel_hozac ? 1157548004 M * matti Yes. 1157548008 M * matti This one :) 1157548031 M * matti daniel_hozac: XID for misteriously hidden process (the chrooted named) is good. 1157548046 M * daniel_hozac ok. 1157548049 M * doener No viewing of any process outside of chroot, even if /proc is mounted 1157548061 M * doener might that kick in? 1157548071 M * matti No. 1157548086 M * matti This means, that chrooted process do not see any other process outside his chroot. 1157548089 M * matti IIRC. 1157548097 M * doener well, you have _two_ chroots 1157548117 M * matti Oh, you mean vserver as first? 1157548161 M * doener yep 1157548189 M * matti doener: xid 1 is seeing this processes. 1157548199 M * matti doener: But... 1157548222 M * matti doener: The guest itself not. 1157548239 M * matti doener: Will this applies to this particular restrictions? 1157548240 M * daniel_hozac matti: try disabling CONFIG_GRKERNSEC_CHROOT_FINDTASK? 1157548251 M * doener I'm checking harry's patch 1157548304 M * matti Done. 1157548304 M * matti rux 3018 # sysctl -w kernel.grsecurity.chroot_findtask=0 1157548305 M * matti kernel.grsecurity.chroot_findtask = 0 1157548318 M * daniel_hozac still doesn't work? 1157548322 M * matti Yes. 1157548325 M * matti Working. 1157548337 M * matti Now I see the named process inside ns2 namespace. 1157548344 M * daniel_hozac so doener gets the cookie ;) 1157548357 M * matti ns2 / # ps aux | grep named 1157548358 M * matti named 7671 0.0 0.4 31036 4256 ? Ssl 01:32 0:11 /usr/sbin/named -u named -n 1 -4 -t /chroot/dns 1157548363 M * doener *smack* 1157548364 M * matti Hm... 1157548380 A * matti hands a homemade delicious cookie to doener... 1157548394 M * matti But. 1157548399 M * matti The question is. 1157548407 M * doener is that intentional? 1157548420 M * daniel_hozac probably not... 1157548426 M * matti Can we fix this behavior? 1157548459 M * matti To move chroot restrictions like this one to lower plane than vserver itself? 1157548465 M * matti Probably now? 1157548467 M * doener bah, using firefox to view the patch _sucks_ 1157548468 M * matti s/now/not/ 1157548519 A * matti dreams about grsecurity capable of separate per-xid settings ;p 1157548525 M * matti Ammhh... 1157548526 M * matti ;] 1157548635 M * daniel_hozac doener: proc_is_chrooted 1157548656 M * daniel_hozac doener, harry: this would need an exception for guests, right? 1157548659 M * doener hm, I'd tend to have_same_root 1157548669 M * daniel_hozac umm, yeah. 1157548680 M * daniel_hozac that makes a lot more sense. 1157548699 M * matti Whhoooo... guys.. 1157548700 M * matti ;p 1157548711 M * harry mkay... we're back!!! 1157548711 M * matti So, this is fixable? Or we need to disable this option? 1157548714 M * matti LOL 1157548716 M * harry damn this! 1157548719 M * matti harry: :) 1157548721 M * daniel_hozac matti: yes :) 1157548723 M * harry cluster problem AND server ordering problem 1157548733 M * harry so that 's all fixed now... 1157548739 M * matti harry: Not really. 1157548748 M * harry how's it going here? 1157548752 M * matti harry: Solved, not fixed. 1157548768 M * matti harry: The CONFIG_GRKERNSEC_CHROOT_FINDTASK needs to be blame. 1157548779 M * harry haha... /me points! ;) 1157548789 M * matti ;-p 1157548804 A * harry checks da code! 1157548813 M * harry but first... da comments :) 1157548835 M * matti Whooo... 1157548852 M * doener daniel_hozac: The only thing I see is extending have_same_root to check againt vx_info->namespace->whatever first, but that will cause some not so neglible overhead I guess (well, no locks AFAICT, but still) 1157548876 M * doener (that one should have addressed harry as well...) 1157548881 M * daniel_hozac doener: hmm, wouldn't fixing have_same_root mean that chroots inside guests will still see the guest's processes? 1157548908 M * doener not if done in the way that I explained ;) 1157548920 M * matti harry: As you can see... daniel_hozac and doener are working on fix/fix-concept right now. 1157548924 M * matti harry: :) 1157548932 M * doener we basically check if we're the first chroot for that context, and if so, we let it pass 1157548933 M * matti harry: I'll go out of cookie today ;p 1157548962 M * doener (check for tsk_a I guess, the one that is trying to see tsk_b) 1157548969 M * harry hehe 1157549080 M * harry i can't follow anymore, sry... another one just passed by here... 1157549089 M * harry can anyone just in very short, update me? 1157549117 M * doener harry: the chroot visibility option of grsec breaks thinsg 1157549121 M * harry problem is, afaict: double chrooted procs are not shown when findtask protection is on 1157549139 M * doener vserver does a chroot -> bind does another one -> vserver cannot see its own bind process 1157549149 M * harry doener: i see... and this needs to be solved in... grsec or vserver or only my patch? 1157549156 M * doener your patch 1157549195 M * matti harry: grsec itself is good. vanilla vserver also. When they work as a team, they fails on findtask. 1157549214 M * harry you basicly shouldn't enable the findtask option in /proc protections... 1157549229 M * harry which... from the comments in the option... is normal :) 1157549243 M * doener I'd suggest to prepend have_same_root with a check that does: check if tsk_a is has an xid, if so, check it's root against the vserver's namespace (somehow), and if it is chrooted only once, treat it as eligible to see tsk_b 1157549249 M * harry so actually, it's not a bug, but a feature you don't want ;) 1157549263 M * matti harry: So, we make system less secured. 1157549266 M * matti harry: In some way. 1157549314 M * harry doener: doesn't that completely override CONFIG_GRKERNSEC_CHROOT_FINDTASK 1157549316 M * harry ? 1157549322 M * matti harry: This is not a bug - this is sure. This is only a miss-conception in a case of vserver usage :| 1157549324 M * daniel_hozac harry: no, it extends it to work in guests. 1157549413 M * harry then... we fix it! :) 1157549425 M * matti ;-) 1157549469 A * matti hands a cup of 0xc0ffee to daniel_hozac, doener and harry :) 1157549475 M * matti And probably one to myself. 1157549479 M * harry hehe tnx ;) 1157549491 M * matti romke: 0xc0ffee? 1157549495 N * Bertl_zZ Bertl 1157549501 M * Bertl morning folks! 1157549506 M * matti Bertl: 0xc0ffee? 1157549508 M * matti Bertl: Hello. 1157549524 M * daniel_hozac morning Bertl! 1157549541 M * prae hi Bertl 1157549564 M * romke matti: thx, drinking one right now... 1157549598 M * matti harry: We can state a warning in _README_ for this or points people to patch (when w'll be ready). 1157549606 M * harry yeah 1157549610 M * harry i'll fix it now :) 1157549617 M * matti harry: CONFIG_GRKERNSEC_CHROOT_FINDTASK is good if you do not plan tu use chrooted services within guests. 1157549645 M * Bertl daniel_hozac, doener: what do you think about this one? http://vserver.13thfloor.at/Stuff/delta-rc31.3.diff 1157549647 M * matti harry: Rest of options stays as they are now. 1157549651 M * harry fixed! ;) 1157549658 M * harry well... the readme is fixed :) 1157549662 M * matti harry: Oh now! So quickly? 1157549669 M * matti harry: Oh, eheheh. 1157549671 M * harry nono... just the readme :) 1157549681 M * matti :> 1157549771 M * nayco Hello, Bertl 1157549772 M * nayco ! 1157549786 M * matti harry: No no... 1157549798 M * matti harry: # CONFIG_GRKERNSEC_CHROOT_FINDTASK is not set - not in such way :) 1157549809 M * matti harry: Leave this as =y. 1157549821 M * matti harry: And just state the BIG FAT WARNING about. 1157549830 M * daniel_hozac Bertl: looks sane... but i don't know what the implications are. 1157549839 M * matti harry: In a case, where users not plan to use chrooted services, this works as it should be. 1157549855 M * harry matti: i'd rather change it so it works in vserver guests...altough i'm looking to see if that makes sense 1157549872 M * matti harry: I see. 1157549891 M * harry my biggest problem is... if i patch it to work in guests... it probably won't work in the rootserver anymore 1157549903 M * harry unless i write some really ugly code around it 1157549910 M * harry but... thinking... brewing stuff in my head... 1157549913 M * matti harry: If you or daniel_hozac or doener - I doubt me... :< - will produce a patch for this, to extedns this to guest namespace, the problem will be solved and fixed. 1157549932 M * matti s/extedns/extends/ 1157550190 J * id23 ~id@p50812671.dip0.t-ipconnect.de 1157550229 M * matti Hehe. 1157550234 M * matti I just realizie. 1157550239 M * daniel_hozac harry: you can leave the behaviour unchanged if current->vxi is NULL. 1157550263 M * matti That we can easily produce immutable not killable and not visible process inside guest with this ;p 1157550266 M * matti Ehehehe. 1157550289 M * matti ;-p 1157550323 M * matti s/realizie/realize/ 1157550324 M * Wonka sounds evil 1157550333 M * matti Very ;] 1157550355 M * Wonka as a vserver host, i'd like to be able to see every guest process, and kill it too 1157550397 M * matti Wonka: Yes, that's why we working on some solution. The simplest one is to disable CONFIG_GRKERNSEC_CHROOT_FINDTASK for now. 1157550415 M * Wonka i'd like some SIGREALLYKILL, which just removes a process from every table it's in, and then frees all it's memory, FDs and stuff 1157550427 M * Wonka (not limited to vservers) 1157550445 M * matti Wonka: SIGULTIMATEKILL ;-p 1157550459 M * Wonka i'd like some interface to most kernel data structures... 1157550484 M * nayco 1157550485 M * Wonka ability to peek at what the scheduler does, and stuff 1157550679 M * matti Wonka: You can state a wish-list to Santa :) 1157550808 M * harry daniel_hozac: that seems like a quite small and easy patch :) 1157550931 M * Wonka lol, matti 1157550991 M * harry http://people.linux-vserver.org/~harry/findtask_fix01.diff 1157551001 M * harry should this work? /me gotta run now... will try later... sr 1157551002 M * harry y 1157551287 Q * XOOM 1157551871 M * Bertl harry: 'current->vxi == NULL' is _not_ a good test :) 1157551886 M * Bertl what do you want to check there? admin context? 1157552407 J * Piet debian-tor@tor-irc.dnsbl.oftc.net 1157552526 Q * Piet 1157552555 J * Piet hiddenserv@tor.noreply.org 1157552575 J * dna ~naucki@43-199-dsl.kielnet.net 1157552588 M * matti Bertl: You probably need to real whole log from discussion... 1157552595 M * matti Bertl: Want some .log file? :) 1157552598 M * matti s/real/read/ 1157552755 M * Bertl matti: in any case, this test is _very_ dubious 1157552812 Q * michal_ Ping timeout: 480 seconds 1157553119 J * michal_ ~michal@www.rsbac.org 1157553320 J * Good_KITTY ~football@tor-irc.dnsbl.oftc.net 1157553326 P * Good_KITTY 1157553352 M * harry Bertl: so... how do i check if it's the root of a vps? 1157553412 J * Desruptive-Kid ~SPeaktoMO@tor-irc.dnsbl.oftc.net 1157553419 P * Desruptive-Kid 1157553460 M * Bertl harry: 'root of a vps'? 1157553529 M * Bertl current->vxi == NULL checks for 'having no context structure assigned' 1157553556 J * Linux-Mastermind ~pear6789@tor-irc.dnsbl.oftc.net 1157553560 Q * Linux-Mastermind Killed (bendy24 (No reason)) 1157553628 J * Shadow-Killer ~kill12344@tor-irc.dnsbl.oftc.net 1157553638 P * Shadow-Killer 1157553801 M * harry Bertl: did you read the "history"? 1157553809 M * essobi_ Hey.. 1157553819 M * essobi_ How's everyone doing this morn? 1157553849 M * harry Wed Sep 6 16:44:08 CEST 2006 1157553852 M * harry ahm... :) 1157553867 M * essobi_ Hehe.. 1157553912 M * essobi_ So has anyone played with the munin setup for vservers? 1157553958 M * Bertl harry: no :) 1157554011 M * Bertl harry: but regardless of the motives elaborated there, this check is dubious and should be rewritten, please just tell me what you want to test for here!? 1157554021 M * harry If you say Y here, processes inside a chroot will not be able to kill, send signals with fcntl, ptrace, capget, setpgid, getpgid, getsid, or view any process outside of the chroot. If the sysctl option is enabled, a sysctl option with name "chroot_findtask" is created. 1157554043 M * harry i know this check is wrong now... but... how do i make it right ;) 1157554063 M * Bertl just what is it supposed to check for?! 1157554071 M * Hollow hey Bertl! did you see the articles on heise.de and golem.de? 1157554077 M * harry the problem is, that when you chroot , the protection that grsecurity enforces with this option is that you can't kill/... processes from outside 1157554087 M * Bertl Hollow: yeah, great work?! 1157554100 M * harry but... this means, if you have a vps (chrooted) and you have e.g. named chrooted 1157554108 M * harry that the vps can't see the named process 1157554116 M * Hollow Bertl: guess so :) lwn, newsforge and /. still missing though 1157554118 M * harry since it's chrooted, and can't see them 1157554125 M * Bertl harry: okay, I got that part 1157554139 M * Hollow Bertl: and i left out LKML, thought you might want to do it there .. 1157554147 M * Bertl harry: but HOW is that related to this change, checking for 'current->vxi == NULL'? 1157554157 M * Bertl Hollow: yep, will do so shortly 1157554177 M * harry 15:43 < daniel_hozac> harry: you can leave the behaviour unchanged if current->vxi is NULL. 1157554209 M * harry i was in a real hurry, so i just thought... let's see what this does... 1157554230 M * harry now... when i'm back, i realize that it isn't a good sollution 1157554234 M * Bertl IMHO it does the opposite of what you had in mind, and in a very dubious way too :) 1157554238 M * harry so i have to come up with a decent one ;) 1157554261 M * harry yeah... writing kernel code when you 're in a hurry is generally a bad idea ;) 1157554282 M * Bertl so, you want to disable or enable this check on the host or inside a guest? 1157554381 M * harry i want this feature to work also for guests 1157554407 M * harry so... if you're in the "root" of a vps, you SHOULD be able to see the chrooted processes 1157554407 M * Bertl hum, so you want to check for a double chroot then? 1157554467 M * Bertl I don't think that grsec is flexible enough to do that 1157554471 M * harry the chroot in the vps should not be able to send signals with fcntl, ptrace, capget, setpgid, getpgid, getsid,... any processes outside the chroot 1157554508 M * Bertl just consider the following (not so unusual) case: 1157554515 M * harry so, named chrooted in a vps should not be able to ... processes in the vps 1157554534 M * Bertl /home -bind-> /vservers/GUEST/home 1157554546 M * Bertl now you chroot into /vservers/GUEST/ 1157554574 M * Bertl is now /home/user/bin/something inside or outside the chroot? 1157554621 M * Hollow sounds like much broken logic in grsec assuming that chroot is some kind of container.. 1157554688 M * harry Bertl: you've got a point there... 1157554758 M * harry Hollow: chroot IS some kind of container ;) 1157554785 M * harry Bertl: it's all about where the process is started imho 1157554813 M * harry if you start it in a chroot, it's inside the chroot, even tough it's bind mounted 1157554825 M * harry so it should be treated that way (correct me if i'm wrong) 1157554945 M * Bertl well, I think what daniel_hozac meant was to enable 'normal' (whatever strange semantics there might be) grsec behaviour for processes on the host 1157554967 M * Bertl but to disbale the entire check inside a guest 1157554988 M * harry that's a possibility too 1157555006 M * harry i'm not sure what i want... and if it's even useful 1157555008 M * Bertl in which case you simply want to add something like: 1157555031 M * Bertl if (!vx_check(0, VX_ADMIN)) return 0; 1157555044 M * Hollow harry: not really, you just change the root entry for a process... but there is no hierarchy... 1157555044 M * Bertl or the other way round 1157555047 M * matti harry, Bertl: Thanks for working on this isse :) 1157555051 M * matti s/isse/issue/ 1157555063 M * matti Bertl: This can be in some way handy in grsec+lvs kernels ;) 1157555084 M * matti Bertl: And this is not a bug - only a miss-concept in grsecurity in a case of vserver usage ;) 1157555159 M * harry http://paste.linux-vserver.org/342 1157555174 M * harry this is the entire function which makes the findtask thingy do what it does 1157555178 M * matti Bertl: This feature limit process within chroot to see only process inside such chroot env, and no process outside. 1157555192 M * harry (but remove the current->vxi check ;)) 1157555204 M * matti Bertl: And this logic fails in a case when vserver is used. I mean, within guest namespace. 1157555212 M * matti harry: Looking :) 1157555272 M * matti harry: Hehehe, looks like very dirty hack :) 1157555292 M * harry why's that? 1157555304 M * matti The "|| !p || current->vxi == NULL)" part :) 1157555315 M * harry that , indeed , was a really dirty hack 1157555322 M * matti I know ;p 1157555332 M * harry it's just that... boss came in, and i had to hurry 1157555334 M * matti harry: What you think about Bertl's solution? 1157555345 M * harry so what do you do... write something shitty ;) 1157555363 M * matti ;-) 1157555387 M * harry matti: well... i wonder if it's useful to do it like Bertl said... 1157555403 M * harry the primary reason you want this kind of protection, is for chroot's on your vps 1157555423 M * harry not on your host 1157555434 M * harry (well.. there too, off course..>) 1157555662 M * harry Bertl: is there an easy way to check wether your chroot is a vps chroot or not? 1157555704 M * Bertl nope, they are identical 1157555712 M * harry hmm... that solves it then... 1157555724 M * Bertl but let me ask how grsec wants to work inside a double chroot? 1157555727 M * harry fixing it the way i want, is "impossible" 1157555765 M * harry Bertl: i don't think that's something they worry about ;) 1157555774 M * harry but i'll definately ask spender about that 1157555785 M * Bertl well, the problem is more the flawed logic there instead of the nice-play with linux-vserver 1157555796 M * harry yeah... 1157555816 M * harry but i'll add your patch to it... that should make it at least work for the root server then :) 1157555819 M * Bertl probably a simple chroot / would break it on a grsec only kernel too :) 1157555830 N * Belu_zZz Belu 1157555845 M * matti Hmm... 1157555856 M * Bertl harry: how does the proc_is_chrooted() work? 1157555904 A * harry runs ctags 1157555912 M * harry (ps. i didn't write grsec, so i don't konw all ;)) 1157555915 J * stefani ~stefani@tsipoor.banerian.org 1157555921 M * Bertl welcome stefani! 1157555925 M * stefani hola. 1157555927 M * matti harry: You're almost as good as spender is ;p 1157555934 M * matti harry: Don't be so shy ;p 1157555934 M * matti ;p 1157555939 A * matti smiles. 1157555944 M * harry lol 1157555946 M * matti ;D 1157556087 M * harry #define proc_is_chrooted(tsk_a) ((tsk_a->pid > 1) && (tsk_a->fs != NULL) && \ ((tsk_a->fs->root->d_inode->i_sb->s_dev != \ child_reaper->fs->root->d_inode->i_sb->s_dev) || \ (tsk_a->fs->root->d_inode->i_ino != \ child_reaper->fs->root->d_inode->i_ino))) 1157556169 M * Bertl eek! :) 1157556211 M * Bertl well, you could probably adjust that to the context child reaper for guest which are running an init, (but this will fail for sysv guests) 1157556229 Q * romke Quit: leaving 1157556281 M * harry stupid backslashes... 1157556286 M * harry you know what it means, i hope ;) 1157556296 M * Bertl yes, I hope so too :) 1157556296 M * harry looks prettier than i pasted ;) 1157556347 M * harry question is... should i change that one there??? 1157556361 M * harry biggest problem is: i didn't write the code... i don't know all the dependencies etc.. 1157556396 M * Bertl well, inside a guest, the child_reaper is not necessarily the reaper in use 1157556425 M * Bertl so, to make it at least partially correct, you would have to adapt checks involving the child_reaper anyways 1157556471 M * doener back now... lost connection and had to buy a new TAE socket... 1157556530 M * Bertl those bastards! now they sell you the sockets to keep connected :) 1157556533 M * doener the old one did never hold the plug reliably, but today it broke completely 1157556575 M * doener well, it was probably a pre-WWII thing according to how well it looked... ;) 1157556587 M * doener s/thing/model/ 1157556615 M * harry Bertl: how comes? 1157556623 M * harry inside a guest, the child_reaper is not necessarily the reaper in use 1157556648 M * doener vserver-init vs. host-init I assume 1157556652 M * Bertl because we have virtualized child reapers for ini based guests 1157556714 M * harry that's true... so child_reaper could point to the wrong init_task... not the one of the guest? 1157556767 M * harry inside a guest, the child_reaper is not necessarily the reaper in use 1157556772 M * harry whoops... sry! 1157556811 A * harry bathroom... brb 1157556820 M * doener Bertl: I thought about adding a check against sth. in the namespace stored in vx_info... but that breaks for non-namespace vservers, right? 1157556947 A * doener wonders if a is_chrooted field in task_struct would hurt so much that it makes that ugly thing necessary in the first place 1157556988 M * Bertl if done properly, no, just check the spectator patches :) 1157557016 M * doener which question did that answer? ;) 1157557048 M * doener oh boy... another debian server hack :( 1157557057 M * Bertl doener: yours :) 1157557095 M * Bertl doener: the last one, regarding 'hurt' 1157557114 M * doener ok, I tried to apply it to the other one ;) 1157557118 M * doener thus I asked 1157557303 M * harry hehe 1157557316 M * harry that would be a nice sollution indeed... 1157557371 M * harry so... what do you think is the best sollution? 1157557380 M * harry just disable that option? 1157557393 M * harry (it DOES enhance security in vservers...) 1157557446 M * harry bleh... /me gotta run (again!) 1157557462 M * harry this time, i'll not be back for 4 hours or so... but i'll read on here... later on :) 1157557476 M * harry cya'll 1157557577 M * Bertl cya 1157558252 Q * matti Ping timeout: 480 seconds 1157558447 J * matti matti@linux.gentoo.pl 1157558499 Q * ||Cobra|| Remote host closed the connection 1157558634 M * matti Uhm. 1157558725 Q * sladen Ping timeout: 480 seconds 1157558770 J * sladen paul@starsky.19inch.net 1157559320 J * bonbons ~bonbons@83.222.36.236 1157559950 A * kir is away: Gone home 1157561067 J * marcfiu ~mef@targe.CS.Princeton.EDU 1157561073 M * marcfiu hello 1157561853 M * Bertl welcome marcfiu! 1157562246 M * doener hi mef 1157562669 M * marcfiu Hi Doener 1157562750 M * Hollow Bertl: btw, did we/you find any solution to the exec-ulimit problem with gcc4.1.1? 1157562789 M * Bertl no, but maybe updating gcc helps there? (haven't tried :) 1157562810 M * Hollow well, gcc 4.1.1 is latest :) 1157563182 M * Bertl latest released, yes 1157563196 M * Bertl but as the gcc folks say: only HEAD is relevant 1157563216 M * doener what is that problem about? 1157563257 M * phreak`` doener: basically http://bugs.gentoo.org/show_bug.cgi?id=138468 1157563288 M * phreak`` Hollow's last 3 comments to be exact 1157563296 Q * gerrit_ Ping timeout: 480 seconds 1157563469 J * kevinp ~kevinp@ny.webpipe.net 1157563671 M * kevinp the main page of the wiki has 2.6.17.7 for the kernel link, it looks like it should be set to 2.6.17.11 1157563712 M * kevinp anybody care if I update it? 1157563756 M * mnemoc kevinp: poke Hollow 1157563788 M * kevinp still going through the process of creating my new account on the new wiki :) 1157563798 M * Hollow the link is correct here 1157563823 M * Hollow or do you mean 2.1.1? 1157563853 M * phreak`` Hollow: the 2.0.2_rc31 one 1157563859 M * kevinp for the devel branch 1157563864 M * phreak`` *2.1.1_rc31 1157563885 M * Hollow fixed 1157563905 M * kevinp thanks 1157564038 J * yarihm ~yarihm@84-75-123-221.dclient.hispeed.ch 1157564374 J * dna_ ~naucki@43-199-dsl.kielnet.net 1157564465 J * kir_home tis-103316@213.152.157.70 1157564507 J * Alissa atnuzdmxqo@151.81.4.118 1157564518 M * Alissa hi all :) 1157564750 Q * dna Ping timeout: 480 seconds 1157565402 Q * dlezcano Ping timeout: 480 seconds 1157565946 Q * Piet Remote host closed the connection 1157566022 J * dlezcano ~dlezcano@AToulouse-252-1-53-110.w83-200.abo.wanadoo.fr 1157566066 J * Piet hiddenserv@tor.noreply.org 1157566538 Q * prae Quit: Quitte 1157566615 Q * Piet Remote host closed the connection 1157566679 J * Piet hiddenserv@tor.noreply.org 1157567149 J * gerrit_ ~gerrit@bi01p1.co.us.ibm.com 1157567337 Q * dna_ Read error: Connection reset by peer 1157568732 Q * yarihm Quit: Leaving 1157570127 M * matti harry: :) 1157570152 M * Alissa hi matti :) 1157570384 M * matti Hi Alissa :)) 1157570459 M * Alissa uhmmm 1157570471 M * Alissa Fedora Core f**k 1157570473 M * Alissa -.-" 1157570574 M * harry tnx for the extremely useful info 1157570612 M * Alissa sorry harry, tonight I'm very very ugry 1157570622 M * matti harry: Hehe. 1157570631 M * matti harry: spender still off-line? 1157570631 M * Alissa Debian guest don't work on fedora core host -.-" 1157570641 M * harry matti: seems so 1157570641 M * matti Alissa: Why? 1157570679 M * matti harry: I run some tests with chrooted sshd :) 1157570684 M * Alissa matti only fedora guest work.. any other guest the network don't work :( 1157570689 M * matti harry: And user -> chrooted home. 1157570691 M * Alissa and I not understand why! : 1157570700 M * matti harry: What you described on #grsecurity applies. 1157570707 M * matti harry: And this should be fixed. 1157570732 M * matti harry: This works in a case of very simple usage of chroot. 1157570740 M * matti harry: Like chrooting daemons, etc. 1157570783 M * matti harry: In other cases... 1157570802 M * matti harry: Correct me if I am wrong. 1157570875 M * harry matti: in normal environments, you never use chroot in chroot 1157570886 M * harry but it's possible, so they might fix it ;) 1157570919 M * matti :) 1157571526 M * Alissa uhmmm 1157571711 J * blade1 ~master@202.125.143.69 1157571712 M * matti Alissa: Hm... 1157571717 M * matti Alissa: Dunno why. 1157571725 M * blade1 hello every body 1157571819 M * matti Hi blade1. 1157571847 J * Alissa` atnuzdmxqo@151.81.1.217 1157571880 M * blade1 matti> what you do>? 1157571916 M * matti What I do? 1157571924 M * matti Why you asking? 1157571941 M * blade1 just chating... 1157571946 Q * kir_home Quit: Ухожу я от вас 1157571954 M * matti Oh. 1157571966 M * blade1 where you from? 1157572072 M * matti Hm, this is not very good channel if you want only chit-chat or talk to somebody ;] 1157572079 M * matti But, we can help you with vserver :) 1157572085 M * matti Or something similar. 1157572096 M * blade1 ok what that server do.? 1157572097 Q * Alissa Ping timeout: 480 seconds 1157572111 M * matti blade1: Look at the link in topic. 1157572116 M * matti blade1: http://linux-vserver.org/ 1157572117 M * blade1 what is vserver... whats it servers>? 1157572129 M * harry blade1: asl? 1157572130 M * harry :p 1157572147 M * matti ;p 1157572177 M * blade1 22 male. 1157572182 M * blade1 and you guys>? 1157572220 A * harry was kidding!!! 1157572229 M * Alissa` matti: I have tried to create a guest debian / slackware / mandriva / etc on a system Fedora Core, but none of these has the net that works. Alone guest Fedoras work. Do you know how to tell me because, or is it my pc that is possessed? :D 1157572233 A * harry doesdn't get it ;) 1157572243 M * matti harry: Hehehe. 1157572283 M * matti Alissa`: Well, maybe Fedora uses some different kernel options? 1157572301 M * Alissa` matti I have compiled a vanilla kernel 1157572321 M * Alissa` the same kernel can I use on other pc (debian sarge) and any guest work... 1157572349 M * matti Alissa`: How this "network is not working" appear? 1157572370 M * Alissa` ping, traceroute, etc 1157572372 M * Alissa` not work 1157572392 M * Alissa` (incoming ping respond, outgoin ping do NOT work) 1157572398 M * matti Some errors? 1157572405 M * matti Warnings? 1157572405 M * Alissa` nothing 1157572411 M * Alissa` nope 1157572416 M * matti And NIC is up in guest?D 1157572448 M * Alissa` yes 1157572531 P * stefani I'm Parting (the water) 1157572558 M * matti Alissa`: Nothin' in logs? 1157572566 M * Alissa` nope 1157572572 M * Alissa` :( 1157572585 M * matti Alissa`: I assume, that you have normal interface allias, right? 1157572602 M * Alissa` eth0, yes 1157572602 M * Hollow you RAW_ICMP ccap for ping to work inside 1157572603 M * matti s/allias/alias/ 1157572606 M * Hollow +need 1157572609 M * Alissa` and public IP's v4 :) 1157572617 M * matti Indeed. 1157572647 M * matti Alissa`: Well if this is your custom kernel. 1157572659 M * matti Alissa`: And other guests on other host machine are working. 1157572663 Q * blade1 Ping timeout: 480 seconds 1157572672 M * matti Alissa`: So, I assume, that you missed something. 1157572681 M * matti Alissa`: In configuration maybe? 1157572703 M * matti Alissa`: This is not a black magic after all :) 1157572777 M * matti Alissa`: Do not give up, and make an impression on us :) 1157572827 M * matti 9.3.2-P1: All users of BIND 9 are encouraged to upgrade to this version. 1157572929 M * Alissa` matti: http://phpfi.com/149737 1157572951 M * matti Alissa`: No, no :) 1157572958 M * Hollow uhm.. RAW_ICMP is a ccap, you set it in /etc/vservers//ccapabilities 1157572963 M * matti Alissa`: Capabilities are set not in kernel config :) 1157572974 M * Hollow per guest setting :) 1157572979 M * matti Yep. 1157572994 M * Alissa` ah! sorry ^^" I'm n00b on vserver ;P 1157573014 M * Alissa` uhmmm you have a sample? 1157573063 M * Hollow hm.. thinking about it.. doesn't util-vserver give this ccap by default? 1157573115 M * Alissa` I use a vserver build -m skeleton, and use a pre-image of this site: http://lylix.net/vps+templates/func,select/id,1/orderby,2/page,2/ 1157573140 M * Hollow uh no.. they are even declared as insecure, rotfl.. 1157573163 M * Alissa` O.o" 1157573200 M * Hollow ah, no.. sorry.... missed a ~ 1157573201 M * Hollow ;) 1157573205 M * Alissa` insecure? why? 1157573222 M * Hollow all beside utsname and raw_icmp are insecure.. 1157573250 M * Hollow well, just do: echo raw_icmp >> /etc/vservers//ccapabilities 1157573425 M * matti :) 1157573712 M * Alissa` Hollow, matti: http://phpfi.com/149745 <= not work : *sigh* 1157573722 M * harry `pak0.pk3' at 3653049 (0%) 18.1K/s eta:7h [Receiving data] 1157573725 M * harry bleh... useless! 1157573751 M * Loki|muh 22:09:49 (1.11 MB/s) - edgy-desktop-i386.iso 1157573752 M * Loki|muh :) 1157573815 M * Hollow Alissa`: do you have iptables rules, or is that box behind some router/firewall whatever? 1157573862 M * Alissa` Hollow I had already thought there, for this I have made iptables -F:P 1157573864 M * Alissa` ^^" 1157573875 M * Alissa` any to any accept :P 1157573883 M * Hollow hm 1157573921 M * Alissa` Hollow on this fedora core host, guest fedora work, other distro not work the network :( 1157573982 A * Hollow shrugs 1157574012 M * Alissa` ?!? 1157574017 M * Loki|muh harry: if you need this file, open a query to me ;) 1157574098 M * Alissa` Hollow don't have idea of which the true problem could be right? ^^" 1157574107 M * harry Loki|muh: i'm downloading them as we speak :) 1157574114 M * Loki|muh okay :) 1157574115 M * harry i have the cd... but in the end... 1157574116 M * Hollow Alissa`: yep ;) 1157574130 M * harry io error 1157574135 M * harry fucking cd is broken 1157574139 M * Loki|muh too bad :( 1157574150 M * Loki|muh so, then I can try now the ubuntu edgy livecd ;) 1157574152 M * Loki|muh bbl 1157574153 M * harry well.. google is friendly ;) 1157574156 M * Loki|muh hrhr 1157574168 M * matti Alissa`: route -n 1157574172 M * harry it gave me doom1 and 2 wadfiles 1157574181 M * harry and quake1 2 and 3 pak files 1157574195 M * harry all because the fucking original cd's here refuse to work :S 1157574249 M * harry timidity++ i386 2.13.2-1 base 9.0 M 1157574254 M * harry nice fucking dependency 1157574265 M * harry anyway... ==> southpark! 1157574272 M * harry enough playing around with my new videocard! 1157574357 Q * FloodServ reticulum.oftc.net charon.oftc.net 1157574357 Q * matti reticulum.oftc.net charon.oftc.net 1157574357 Q * id23 reticulum.oftc.net charon.oftc.net 1157574357 Q * Alissa` reticulum.oftc.net charon.oftc.net 1157574357 Q * dlezcano reticulum.oftc.net charon.oftc.net 1157574357 Q * kevinp reticulum.oftc.net charon.oftc.net 1157574357 Q * bonbons reticulum.oftc.net charon.oftc.net 1157574357 Q * marcfiu reticulum.oftc.net charon.oftc.net 1157574357 Q * lilalinux reticulum.oftc.net charon.oftc.net 1157574357 Q * Loki|muh reticulum.oftc.net charon.oftc.net 1157574357 Q * wenchien reticulum.oftc.net charon.oftc.net 1157574357 Q * hap reticulum.oftc.net charon.oftc.net 1157574357 Q * click reticulum.oftc.net charon.oftc.net 1157574357 Q * [PUPPETS]Gonzo reticulum.oftc.net charon.oftc.net 1157574357 Q * bogus reticulum.oftc.net charon.oftc.net 1157574357 Q * tokkee reticulum.oftc.net charon.oftc.net 1157574357 Q * mcp reticulum.oftc.net charon.oftc.net 1157574357 Q * Greek0 reticulum.oftc.net charon.oftc.net 1157574357 Q * independence reticulum.oftc.net charon.oftc.net 1157574357 Q * DreamerC reticulum.oftc.net charon.oftc.net 1157574357 Q * ntrs reticulum.oftc.net charon.oftc.net 1157574357 Q * ag- reticulum.oftc.net charon.oftc.net 1157574357 Q * FireEgl reticulum.oftc.net charon.oftc.net 1157574357 Q * weasel reticulum.oftc.net charon.oftc.net 1157574357 Q * kaner reticulum.oftc.net charon.oftc.net 1157574357 Q * fosco reticulum.oftc.net charon.oftc.net 1157574357 Q * nokoya reticulum.oftc.net charon.oftc.net 1157574357 Q * ebiederm reticulum.oftc.net charon.oftc.net 1157574357 Q * cehteh reticulum.oftc.net charon.oftc.net 1157574357 Q * derjohn reticulum.oftc.net charon.oftc.net 1157574357 Q * anonc reticulum.oftc.net charon.oftc.net 1157574357 Q * lylix reticulum.oftc.net charon.oftc.net 1157574357 Q * micah reticulum.oftc.net charon.oftc.net 1157574357 Q * ruskie reticulum.oftc.net charon.oftc.net 1157574357 Q * Belu reticulum.oftc.net charon.oftc.net 1157574357 Q * cdrx reticulum.oftc.net charon.oftc.net 1157574357 Q * glut reticulum.oftc.net charon.oftc.net 1157574357 Q * rob-84x^ reticulum.oftc.net charon.oftc.net 1157574357 Q * bubulak reticulum.oftc.net charon.oftc.net 1157574357 Q * kir reticulum.oftc.net charon.oftc.net 1157574357 Q * Vudumen reticulum.oftc.net charon.oftc.net 1157574357 Q * Zaki reticulum.oftc.net charon.oftc.net 1157574357 Q * mugwump reticulum.oftc.net charon.oftc.net 1157574357 Q * tanjix reticulum.oftc.net charon.oftc.net 1157574357 Q * Snow-Man reticulum.oftc.net charon.oftc.net 1157574357 Q * phreak`` reticulum.oftc.net charon.oftc.net 1157574357 Q * Piet reticulum.oftc.net charon.oftc.net 1157574357 Q * lolilol reticulum.oftc.net charon.oftc.net 1157574357 Q * mountie reticulum.oftc.net charon.oftc.net 1157574357 Q * Johnnie reticulum.oftc.net charon.oftc.net 1157574357 Q * phedny reticulum.oftc.net charon.oftc.net 1157574357 Q * mnemoc reticulum.oftc.net charon.oftc.net 1157574357 Q * Adrinael reticulum.oftc.net charon.oftc.net 1157574357 Q * blizz reticulum.oftc.net charon.oftc.net 1157574357 Q * michal_ reticulum.oftc.net charon.oftc.net 1157574357 Q * Revelator reticulum.oftc.net charon.oftc.net 1157574357 Q * meandtheshell reticulum.oftc.net charon.oftc.net 1157574357 Q * Hollow reticulum.oftc.net charon.oftc.net 1157574357 Q * eyck reticulum.oftc.net charon.oftc.net 1157574357 Q * pagano reticulum.oftc.net charon.oftc.net 1157574357 Q * Wonka reticulum.oftc.net charon.oftc.net 1157574357 Q * nib-nico reticulum.oftc.net charon.oftc.net 1157574357 Q * cohan_ reticulum.oftc.net charon.oftc.net 1157574357 Q * nox reticulum.oftc.net charon.oftc.net 1157574357 Q * daniel_hozac reticulum.oftc.net charon.oftc.net 1157574357 Q * dhansen reticulum.oftc.net charon.oftc.net 1157574357 Q * Hunger reticulum.oftc.net charon.oftc.net 1157574357 Q * nebuchadnezzar reticulum.oftc.net charon.oftc.net 1157574357 Q * fs reticulum.oftc.net charon.oftc.net 1157574357 Q * sid3windr reticulum.oftc.net charon.oftc.net 1157574357 Q * waldi reticulum.oftc.net charon.oftc.net 1157574357 Q * gerrit_ reticulum.oftc.net charon.oftc.net 1157574357 Q * sladen reticulum.oftc.net charon.oftc.net 1157574357 Q * Skram reticulum.oftc.net charon.oftc.net 1157574357 Q * cryptronic reticulum.oftc.net charon.oftc.net 1157574357 Q * abi reticulum.oftc.net charon.oftc.net 1157574357 Q * ex reticulum.oftc.net charon.oftc.net 1157574357 Q * suka reticulum.oftc.net charon.oftc.net 1157574357 Q * meebey reticulum.oftc.net charon.oftc.net 1157574357 Q * Medivh reticulum.oftc.net charon.oftc.net 1157574357 Q * bragon reticulum.oftc.net charon.oftc.net 1157574357 Q * pusling reticulum.oftc.net charon.oftc.net 1157574357 Q * ray6 reticulum.oftc.net charon.oftc.net 1157574357 Q * SNy reticulum.oftc.net charon.oftc.net 1157574357 Q * samuel_ reticulum.oftc.net charon.oftc.net 1157574367 J * cdrx ~legoater@cap31-3-82-227-199-249.fbx.proxad.net 1157574367 J * glut glut@no.suid.pl 1157574367 J * nokoya ~young@hi-230-82.tm.net.org.my 1157574367 J * Belu B.Lukas@mail.openvcp.org 1157574367 J * lylix ~eric@dynamic-acs-24-154-53-234.zoominternet.net 1157574367 J * ebiederm ~eric@ebiederm.dsl.xmission.com 1157574367 J * cehteh ~ct@cehteh.homeunix.org 1157574367 J * ruskie ~ruskie@ruskie.user.oftc.net 1157574367 J * derjohn ~derjohn@80.69.37.19 1157574367 J * micah ~micah@micah.riseup.net 1157574367 J * anonc ~anonc@staffnet.internode.com.au 1157574367 J * rob-84x^ rob@submarine.ath.cx 1157574367 J * bubulak ~bubulak@whisky.pendo.sk 1157574367 J * kir ~kir@swsoft-mipt-nat.sw.ru 1157574367 J * Vudumen 4750fd0049@perverz.hu 1157574367 J * Zaki ~Zaki@212.118.126.43 1157574373 J * gerrit_ ~gerrit@bi01p1.co.us.ibm.com 1157574373 J * sladen paul@starsky.19inch.net 1157574373 J * Skram ~Mark@hermes.sentiensystems.com 1157574373 J * cryptronic crypt@mail.openvcp.org 1157574373 J * abi ~abi@enz.schiach.de 1157574373 J * ex ex@valis.net.pl 1157574373 J * suka ~suka@bi01p1.co.us.ibm.com 1157574373 J * meebey meebey@booster.qnetp.net 1157574373 J * ray6 ~ray@vh5.gcsc2.ray.net 1157574373 J * samuel_ ~samuel@jupe.quebectelephone.com 1157574373 J * pusling pusling@195.215.29.124 1157574373 J * bragon ~weechat@sd866.sivit.org 1157574373 J * SNy 6cfbac777d@bmx-chemnitz.de 1157574373 J * Medivh ck@paradise.by.the.dashboardlight.de 1157574379 J * FireEgl FireEgl@Sebastian.Atlantica.US 1157574379 J * weasel ~weasel@weasel.noc.oftc.net 1157574396 J * Piet hiddenserv@tor.noreply.org 1157574396 J * lolilol hiddenserv@tor.noreply.org 1157574396 J * mountie ~mountie@CPEdeaddeaddead-CM000a739acaa4.cpe.net.cable.rogers.com 1157574396 J * Johnnie ~jdlewis@static-acs-24-154-32-33.zoominternet.net 1157574396 J * phedny ~mark@volcano.p-bierman.nl 1157574396 J * mnemoc ~amery@kilo105.server4you.de 1157574396 J * Adrinael adrinael@hoasb-ff09dd00-79.dhcp.inet.fi 1157574396 J * blizz ~blizz@evilhackerdu.de 1157574417 J * Alissa` atnuzdmxqo@151.81.1.217 1157574417 J * dlezcano ~dlezcano@AToulouse-252-1-53-110.w83-200.abo.wanadoo.fr 1157574417 J * kevinp ~kevinp@ny.webpipe.net 1157574417 J * marcfiu ~mef@targe.CS.Princeton.EDU 1157574417 J * bonbons ~bonbons@83.222.36.236 1157574417 J * matti matti@linux.gentoo.pl 1157574417 J * id23 ~id@p50812671.dip0.t-ipconnect.de 1157574417 J * independence ~independe@marcusson.no-ip.com 1157574417 J * lilalinux ~plasma@dslb-084-058-196-163.pools.arcor-ip.net 1157574417 J * Loki|muh loki@satanix.de 1157574417 J * FloodServ services@services.oftc.net 1157574417 J * DreamerC ~dreamerc@61-224-133-132.dynamic.hinet.net 1157574417 J * ntrs ~ntrs@68-188-51-87.dhcp.stls.mo.charter.com 1157574417 J * ag- ag@caladan.roxor.cx 1157574417 J * wenchien ~wenchien@59-105-176-11.adsl.static.seed.net.tw 1157574417 J * [PUPPETS]Gonzo gonzo@langweiligneutral.deswahnsinns.de 1157574417 J * hap ~penso@212.27.33.226 1157574417 J * tokkee tokkee@casella.verplant.org 1157574417 J * mcp ~hightower@wolk-project.de 1157574417 J * bogus ~bogusano@fengor.net 1157574417 J * Greek0 ~greek0@85.255.145.201 1157574417 J * click click@ti511110a080-2980.bb.online.no 1157574435 M * Belu uha feeling like quakenet... 1157574448 M * Alissa` matti incoming ICPM work, OUTGOIN not work! ^^" 1157574452 M * Alissa` (apt-get et simila not work) 1157574459 J * Hunger Hunger.hu@213.163.11.138 1157574459 J * nebuchadnezzar ~nebu@zion.asgardr.info 1157574459 J * fs fs@213.178.77.98 1157574459 J * waldi ~waldi@83.137.100.38 1157574459 J * sid3windr luser@bastard-operator.from-hell.be 1157574464 J * mugwump ~samv@watts.utsl.gen.nz 1157574464 J * tanjix ~tanjix@office.star-hosting.de 1157574464 J * Snow-Man ~sfrost@kenobi.snowman.net 1157574464 J * phreak`` ~phreak``@140.211.166.183 1157574467 J * michal_ ~michal@www.rsbac.org 1157574467 J * Revelator ~Efnet@62.128.240.117 1157574467 J * meandtheshell ~markus@85-124-233-117.work.xdsl-line.inode.at 1157574467 J * Hollow ~hollow@2001:a60:f026::1 1157574467 J * eyck eyck@ghost.anime.pl 1157574467 J * pagano ~pagano@131.154.5.20 1157574467 J * Wonka produziert@chaos.in-kiel.de 1157574467 J * nib-nico ~nico@nibweb.net 1157574467 J * cohan_ ~cohan@koniczek.de 1157574467 J * nox ~nox@nox.user.oftc.net 1157574467 J * dhansen ~dave@sprucegoose.sr71.net 1157574467 J * daniel_hozac ~daniel@c-2c1472d5.010-230-73746f22.cust.bredbandsbolaget.se 1157574513 M * matti Alissa`: resolv.conf is present? 1157574524 J * kaner kaner@strace.org 1157574524 J * fosco fosco@konoha.devnullteam.org 1157574952 J * dna_ ~naucki@43-199-dsl.kielnet.net 1157575095 J * Aiken ~james@tooax6-029.dialup.optusnet.com.au 1157575164 M * Bertl Alissa`: what do you mean with outgoing ICMP? 1157575209 M * Alissa` Bertl ANY connection to internet to guest 1157575214 M * Alissa` ^^" 1157575225 M * Alissa` ups, sorry 1157575232 M * Alissa` *to internet from guest... 1157575245 M * daniel_hozac so telnet 64.223.167.99 80 doesn't work? 1157575261 M * Alissa` Bertl http://phpfi.com/149745 1157575268 M * Alissa` nothis 1157575294 M * Alissa` * nothing doesn't go out, as if it were connected to internet 1157575330 M * daniel_hozac is it? have you assigned the guest an IP address? 1157575350 Q * bonbons Quit: Leaving 1157575357 M * Alissa` daniel_hozac http://phpfi.com/149747 <= public IP andress 1157575359 M * Alissa` :) 1157575391 M * Bertl okay, let's fire up 'tcpdump -vvnei eth0' (or whatever interface is used) and do the following ping from inside the guest 'ping -c 1 72.14.221.99' 1157575411 M * Alissa` Bertl ok, wait I can install tcpdump... 1157575417 M * Bertl then please upload the tcpdump output (mabye add icmp to the command if you have 'other' traffic) 1157575441 M * Bertl tcpdump on the host, that is :) 1157575658 M * Alissa` :) 1157575668 M * matti :) 1157576233 M * Alissa` Bertl http://phpfi.com/149763 1157576272 M * Alissa` Bertl ingnore the ip's: 216.75.63.90 (host server) 151.81.1.217 (my ip :P) 1157576287 M * matti Alissa`++ 1157576323 M * Alissa` matti yep? 1157576336 M * matti Nothin' :) 1157576360 M * Bertl 04:55:20.800365 00:15:f2:d6:7e:17 > 00:09:b6:93:d6:80, ethertype IPv4 (0x0800), length 98: (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto: ICMP (1), length: 84) 216.75.63.63 > 72.14.221.99: ICMP echo request, id 1360, seq 12, length 64 1157576373 M * Bertl so I assume 216.75.63.63 is your guest, yes? 1157576379 M * Alissa` yes! ^^ 1157576394 M * Bertl so the icmp echo request _is_ sent out, right? 1157576423 M * Alissa` tcpdump to host, ping to guest... 1157576427 M * Bertl just your router (or whatever is the next hop) either does not relay it, or the answer is lost somewhere 1157576439 M * Alissa` uhmm 1157576465 M * Alissa` Bertl this guest is mandriva (I have installed other guest) not work 1157576471 M * Alissa` Fedora core guest work 1157576471 M * Bertl let's try with a ping to another host where you can run tcpdump on 1157576496 M * Bertl (instead of the google ip) 1157576515 M * Alissa` Bertl http://phpfi.com/149766 1157576519 M * Bertl Alissa`: I assume the Fedora guest has a different ip address, right? 1157576520 M * Alissa` this is a fedora guest 1157576523 M * Alissa` and work... 1157576527 M * Alissa` Bertl yes 1157576541 M * Alissa` 216.75.24.172 1157576543 M * Bertl try to switch the ip addresses between them, the behaviour will change :) 1157576550 M * Alissa` uhmmm... 1157576551 M * Alissa` ok :) 1157576562 A * Alissa` test... away to 5 minutes... 1157576662 M * matti ;] 1157576772 A * Alissa` is back... 1157576776 M * Alissa` not work :( 1157576787 M * Alissa` amen... 1157576812 M * Bertl did you switch the ips between guests, and restart them? 1157576864 M * Alissa` yes 1157576873 Q * micah Ping timeout: 480 seconds 1157576878 M * Alissa` I'm not stupid girl... I'm n00b :P 1157576945 M * Wonka n00bs are stupid people who won't learn. the other ones are newbies. 1157576960 M * Alissa` lol 1157576961 M * Bertl and still the FC guest works, but the MDK one fails? 1157576968 M * Alissa` Bertl yep 1157577013 M * Bertl that is very unusual, as it means that the guest somehow influences decisions outside the host (at least it looks like :) 1157577036 M * Bertl let's try a few things on the host ... 1157577054 M * Bertl ping -c 2 -I 216.75.63.63 72.14.221.99 1157577071 M * Bertl the other guest (FC) has 216.75.24.172 ? 1157577128 J * micah ~micah@micah.riseup.net 1157577135 M * Bertl wb micah! 1157577159 M * Alissa` ... 1157577163 M * Alissa` I have solved! 1157577164 M * Alissa` -.- 1157577177 M * Bertl hmm? 1157577179 M * Alissa` My ISP have blocked /32 of my range IP's 1157577182 M * Alissa` -.-""" 1157577184 M * Alissa` grrrrrr 1157577212 M * Bertl well, that is what I expected, but please explain to me how the FC guest could work with that IP then? 1157577262 M * Alissa` Bertl FC is on another /32 range ^^" 1157577279 M * Alissa` 216.75.24.172 <= FC 216.75.63.63 <= MD 1157577283 M * Alissa` ;) 1157577292 M * daniel_hozac /32 isn't a range... 1157577294 M * Bertl yes, and I asked you to switch them, no? 1157577329 M * Alissa` daniel_hozac I have a 2 C range of IP 1157577329 M * Alissa` ;) 1157577346 M * Alissa` I have requested a B range, but the ISP have denied the request :( 1157577347 M * daniel_hozac doesn't change the fact that /32 is a single IPv4 address. 1157577359 M * Alissa` daniel_hozac OK! I have understand! :P 1157577425 M * matti Alissa`: You see :) 1157577432 M * matti Alissa`: Now you have answer :) 1157577470 M * Alissa` matti must I pay a turn of beer to everybody now? :P 1157577496 M * matti Alissa`: Now, not really - but I speak for myself ;] 1157577501 M * matti s/Now/Not/ 1157577526 M * Alissa` lol 1157578361 Q * dna_ Quit: Verlassend 1157578967 Q * meandtheshell Quit: bye bye ... 1157579122 Q * id23 Ping timeout: 480 seconds 1157580623 Q * mire Quit: Leaving 1157581062 P * marcfiu 1157581369 Q * Alissa` 1157581436 J * serving ~serving@86.108.86.232 1157581786 M * serving FATAL: kernel too old when vserver vname enter 1157581802 M * serving is this host problem or guest problem ? 1157581892 M * serving host running 2.4 kernel .. I am attempting to run fc5 guest .. 1157581931 M * serving please help :) 1157582091 A * Belu is away (ill be back later...) 1157582091 N * Belu Belu_zZz 1157582185 Q * lilalinux Remote host closed the connection 1157582209 M * kevinp I've never seen that error before but I would say it is a host problem 1157582221 M * kevinp since the guest doesn't run it's own kernel 1157582235 M * kevinp what does uname -a give you on the host? 1157582285 M * serving 2.4.23-vs1.22 #2 SMP 1157582307 M * kevinp that is pretty old :) 1157582310 M * serving I don't have this problem with my fc2 guest 1157582331 M * serving what can I do? it didnt break ;) 1157582366 M * kevinp take a look at the tool's source and see why it would give that error? 1157582382 M * kevinp it might give you a clue to why 1157582405 M * kevinp I'm not a programmer, just a user, so if you need more help you'll have to wait for someone else to help 1157582423 M * kevinp maybe daniel_hozac has seen this one? 1157582472 M * serving daniel_hozac has old servers too ? :D 1157582491 M * kevinp not sure about that, but has experience with fc5 and the tools too 1157582496 M * serving thanx kevinp .. I ll dig some more :) 1157582503 M * kevinp np 1157583249 M * Bertl serving: it means that the 'kernel' string presented to your guest is _too old_ for the glibc libraries inside 1157583294 M * Bertl serving: this can have two reasons, a) the kernel is really too old for that libc, or b) the kernel string presented to that libc cannot be parsed properly 1157583517 M * serving hi Bertl.. thanx for you input .. 1157583535 M * serving can I do anything about the passed string ? 1157583632 M * Bertl uts virtualization can help there 1157583642 M * Bertl but not sure that version supports this 1157583655 M * Bertl (latest 2.4 version is vs1.2.11 :) 1157583705 M * serving I am using vserver-admin-0.29-1 1157583705 M * serving vserver-0.29-1 1157583714 M * serving with 2.4.23-vs1.22 #2 SMP 1157583839 M * matti Is possible, that vserver is causing "w" command to be blind? I am curious. 1157583868 M * matti I assume, that this is releated to grsecurity, but I don't have such w blindness on other machines with it. 1157583887 M * matti This is harmless issue, but as I said - I'm curious :) 1157583951 M * matti And strace on /usr/bin/w shows, that it is reading some data... Huh... weirdness++ 1157584069 M * Bertl maybe some patch interaction like the chroot stuff? 1157584118 M * Bertl w works fine on vanilla vserver 1157584283 M * matti Maybe. 1157584299 M * matti who is using wtmp/utmp, and w seems to read some proc stuff. 1157584321 M * matti And since grsecurity enforces some protection on it... Oh well. 1157584353 M * matti Bertl: I see, that you're not much of a grsecurity fan. 1157584354 M * matti ;] 1157584375 M * Bertl I have no problem with grsec at all 1157584397 M * matti And you're using it with vserver i.e. harry's patches? 1157584429 M * Bertl nope, I see no reason for that, the thing is, in certain areas grsec and vserver do similar things in slightly different ways 1157584454 M * Bertl and most of the grsec 'benefits' do not apply to vserver and vice versa ... 1157584461 M * matti And this may cause some troubles. 1157584526 M * Bertl so, a grsec for Linux-VServer might make sense (folks failed to show me where it actually helps) but the crossbreeds IMHO will always cause lower security and grief ... 1157584600 M * Bertl for example: what do I need to hide processes inside a chroot, when I can put the chroot into a separate lightweight guest in the first place? 1157584645 M * matti Depends of point of view. 1157584661 M * matti Limiting user to seen his own process only is not such a bad idea at all? 1157584667 M * matti Correct me if I am wrong? 1157584732 M * Bertl I would not see why that would be a benefit? 1157584747 M * Bertl but again, I could easily put each user into a separate guest 1157584764 M * Radiance i think it helps to protect the host itself where the guest (vps) is part of 1157584788 M * Bertl Radiance: pardon? 1157584823 M * Radiance the point is that i use it since it fixes certain parts of the kernel which don't have made it yet in the main kernel 1157584831 M * Radiance not talking about the vserver patch itself btw :) 1157584835 M * matti Bertl: But overhead of many separate guest will be much more grater than simply made kernel-space restrictions? 1157584853 M * matti Bertl: Well, Radiance is right. 1157584868 M * Bertl matti: no, that's the point of Linux-VServer, there _is_ no overhead :) 1157584869 M * Radiance i'm just happy they're both working together perfectly hehe 1157584895 M * matti Bertl: pipacs (the author of pax) and spender, not only added some features, but also fixed lot of crappy code in kernel. 1157584904 M * matti Bertl: And you know well, that Linus is security ignorant. 1157584919 M * Radiance Berti, and thanks again for the great work you put in vserver if i didn't say that already :) 1157584927 M * Bertl well, kernel fixes are fine 1157584935 M * Radiance BertI, exactly! 1157584941 M * Bertl they should be broken out and submitted 1157584966 M * Radiance that's the main reason i apply it, it protects against even certain private zero's which are not made public by spender and such 1157584971 M * Bertl Radiance: you're welcome! 1157584978 M * matti Radiance: Indeed. 1157585003 M * matti Radiance: Everybody also knows, that grsecurity itself is not much of a "ultimate security solution". 1157585023 M * matti Radiance: It only makes some nasty thing harder to do. 1157585033 M * Bertl but have you ever considered how many security holes a combination might add? 1157585047 M * Radiance indeed 1157585053 M * matti Bertl: I never saw majow vulnerable in grsecurity. 1157585061 M * matti Bertl: And only one hole in my whole life in pax :) 1157585070 M * matti s/majow/major/ 1157585084 M * Bertl okay, but just look at the kernel behaviour 1157585094 M * Bertl - grsec alone (fine) 1157585098 M * matti Yes. 1157585103 M * Bertl - vserver alone (fine) 1157585117 M * matti I know. 1157585122 M * Bertl - combo patches (this and that breaks, doesn't work, needs special handling) 1157585139 M * Bertl now extrapolate that to the security aspects ... 1157585147 M * matti Yes, I hope you didn't right, but you are 1157585148 M * matti :< 1157585152 M * Radiance BertI, well i didn't consider that to be honest, but i think it's worth it since both solutions have a solid history and until now i didn't notice problems despite heavy use and multi-user uses 1157585154 M * Bertl (which are not that simple to check than process visibility) 1157585172 M * matti Radiance: No, no. 1157585180 M * matti Radiance: Bertl is 100% right. 1157585195 M * matti Radiance: vserver and grsecuirty patches are only merge of both. 1157585201 M * Radiance true 1157585216 M * matti Radiance: There's no 100% compatibility, because nobody never perform ture tests. 1157585229 M * Radiance i don't have the capability to investigate on such a level what "new" issues could occur because of such merges heh 1157585245 M * Radiance agreed 1157585249 M * matti Radiance: And as Bertl said, lot things in grsecurity in handled in slightly different fashion than vserver is. 1157585299 M * matti Radiance: For example - today's process hiding issue. 1157585316 M * matti Radiance: I am sure, that spender newer thought about such way of using chroots. 1157585347 M * Radiance ah you mean doing something similar as what happens in vserver ? 1157585402 M * matti Radiance: I mean the issue with process drops out of context if their chrooted within guest. 1157585419 M * matti Radiance: Such process are not visible in guest namespace anymore. 1157585431 M * matti Radiance: You cannot kill it, and so on... 1157585447 M * Radiance i see, this issue happens in grsec ? 1157585482 M * matti Well, with vanilla grsecurity their just invisible :) 1157585486 Q * ag- Quit: BRB 1157585504 M * matti Sorry fro typos - I am tired. 1157585507 M * matti s/fro/for/ 1157585523 J * ag- ag@caladan.roxor.cx 1157585552 M * Bertl ag-: that was quick :) 1157585556 M * matti Heheh. 1157585574 M * Radiance :-) 1157585771 M * ag- Bertl: indeed ;) 1157585843 M * ag- it was quite some time i hadn't spoken here... 1157585851 M * matti ag-: You would probably win the "shorest possible brb ever" contest. :) 1157585880 J * shedi ~siggi@inferno.lhi.is 1157585923 M * matti Bertl: BTW, can you point at code where grsecurity patch can break vserver? 1157585965 M * ag- Bertl: what's the status of vserver ngnet and native ipv6 support right now? 1157586464 J * serving- ~serving@86.108.86.232 1157586514 M * Bertl ag-: ngnet is still on hold, ipv6 exists in experimental patches from bonbons 1157586563 M * Bertl matti: we had the chroot check today, it uses child_reaper which is not necessarily the child reaper inside a guest ... 1157586612 M * matti Bertl: Hmm... 1157586686 M * ag- Bertl: on hold till the virtualisation stuff is done in mainline? 1157586705 M * Bertl until we have something to test from mainline 1157586742 M * Bertl currently lkml folks are not even sure at which layer the virtualization should be done 1157586786 A * matti wishes both vserver and Xen. 1157586795 M * matti As they can co-exists w/o problems :) 1157586841 M * Bertl well, you can do that right now ... but one thing is sure, the Linux-VServer isolation is not enough for some of the involved parties 1157586856 M * matti Not enough? 1157586859 M * matti Where? 1157586869 M * Bertl (especially checkpointing and context migration have 'other' requirements) 1157586892 Q * serving Ping timeout: 480 seconds 1157586933 Q * ag- 1157586966 A * matti will never understand kernel guys. 1157586983 M * Bertl :) 1157586984 M * matti They added such bloat like seccomp and bsd like secure levels. 1157586986 M * matti :0 1157586997 M * matti But they do not want proven pice of code. 1157586999 M * matti Ehh... :) 1157587053 J * ag- ag@caladan.roxor.cx