1246666120 M * Bertl k, just uplaoded the first 2.6.30 pre patch, it doesn't have disk limits or vroot stuff, and ocfs as well as reiserfs (does anybody still use that?) and ipv6 needs some fixing (i.e. do not enable them without previous fixes)
1246666148 M * Bertl I'd appreciate some feedback on the rest and as usual, patches are always welcome
1246668479 Q * Piet Remote host closed the connection
1246668529 J * Piet ~piet@659AAAXCU.tor-irc.dnsbl.oftc.net
1246671615 Q * Radiance Ping timeout: 480 seconds
1246672421 J * Floops[w]1 ~baihu@205.214.201.176
1246672823 Q * Floops[w] Ping timeout: 480 seconds
1246674032 M * Bertl off to bed now ... have a good one everyone!
1246674037 N * Bertl Bertl_zZ
1246675769 J * esa` bip@62.123.65.116
1246675784 Q * esa Ping timeout: 480 seconds
1246676441 J * saulus_ ~saulus@c135014.adsl.hansenet.de
1246676849 Q * SauLus Ping timeout: 480 seconds
1246676856 N * saulus_ SauLus
1246677036 J * esa bip@62.123.79.247
1246677059 Q * esa` Ping timeout: 480 seconds
1246677683 J * esa` bip@62.123.65.116
1246677698 Q * esa Ping timeout: 480 seconds
1246677698 Q * geb Remote host closed the connection
1246678404 Q * esa` Remote host closed the connection
1246678419 J * esa bip@62.123.65.116
1246678959 Q * esa Remote host closed the connection
1246678975 J * esa bip@62.123.65.116
1246679532 J * esa` bip@62.123.12.212
1246679549 Q * esa Ping timeout: 480 seconds
1246680179 J * esa bip@62.123.13.224
1246680194 Q * esa` Ping timeout: 480 seconds
1246680528 Q * hparker Remote host closed the connection
1246680915 J * esa` bip@62.123.64.209
1246680929 Q * esa Ping timeout: 480 seconds
1246681565 J * esa bip@ppp-62-123-66-50.dial.atlanet.it
1246681579 Q * esa` Ping timeout: 480 seconds
1246681845 Q * balbir_ Read error: Operation timed out
1246682705 J * balbir_ ~balbir@122.172.14.223
1246689209 Q * balbir_ Ping timeout: 480 seconds
1246689875 J * balbir_ ~balbir@122.172.30.129
1246691105 M * arachnist Bertl_zZ: thanks :) now i have a 2.6.30.1 + xen + vserver that compiles. will try if it at least boots in a moment
1246692020 J * dna ~dna@128-205-103-86.dynamic.dsl.tng.de
1246692856 J * zbyniu_ ~zbyniu@ip-62.181.188.13.static.crowley.pl
1246692903 Q * zbyniu Ping timeout: 480 seconds
1246693643 Q * balbir_ Read error: Connection reset by peer
1246693976 Q * zbyniu_ Ping timeout: 480 seconds
1246693977 J * mxs mxs@p4FCCAACF.dip.t-dialin.net
1246694064 M * mxs has anybody been using vserver + ext4 successfully ? Getting plenty of stacktraces, though that may be unrelated.
1246694105 M * mxs one thing that definitely seems odd is #define EXT4_MOUNT_TAGGED(1<<24) /* Enable Context Tags */ since that seems to clash with #define EXT4_MOUNT_JOURNAL_ASYNC_COMMIT0x1000000 /* Journal Async Commit */
1246694115 M * mxs (1<<24 == 0x1000000)
1246694130 M * mxs so I'm wondering whether it has ever been tested :)
1246694268 J * zbyniu ~zbyniu@ip-62.181.188.13.static.crowley.pl
1246694344 M * mxs (in ext4.h)
1246694615 J * balbir_ ~balbir@122.172.12.181
1246694689 Q * dna Ping timeout: 480 seconds
1246694781 M * mxs (as for why stacktraces may be unrelated: went from 2.6.29.5+grsecurity 2.1.14 to that + vserver 2.3.0.36 (patch against vanilla 2.6.29.5), integrating the patches (this is where I may have gone wrong; the integration looks fine to me, but I am not
1246694821 M * mxs familiar enough with either codebase to say that for certain; only "real" changes made were to use atomic_inc/dec/read for init_fs.users instead of ++/--, rest was canonical insertion merging
1246696200 M * arachnist hmm... my 2.6.30.1 + xen dom0 + vserver kernel doesn't even boot
1246696416 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1246697087 Q * berth Quit: BitchX: the fresh-maker!
1246697369 J * ktwilight_ ~keliew@87.76-65-87.adsl-dyn.isp.belgacom.be
1246697758 Q * ktwilight__ Ping timeout: 480 seconds
1246698549 J * ktwilight__ ~keliew@161.6-240-81.adsl-dyn.isp.belgacom.be
1246698704 J * ktwilight ~keliew@7.50-240-81.adsl-dyn.isp.belgacom.be
1246698962 Q * ktwilight_ Ping timeout: 480 seconds
1246699049 Q * ktwilight__ Ping timeout: 480 seconds
1246699762 M * mxs that flag overlap was not the cause of the stack traces (though it remains a bug). Now to figure out what is going wrong ...
1246701468 Q * balbir_ Read error: Connection reset by peer
1246702009 Q * SauLus Read error: Connection reset by peer
1246702237 J * balbir_ ~balbir@122.172.32.52
1246702284 J * mxs_ mxs@p4FCCB901.dip.t-dialin.net
1246702595 Q * mxs Ping timeout: 480 seconds
1246702704 Q * esa Quit: Coyote finally caught me
1246704427 J * ktwilight_ ~keliew@10.5-241-81.adsl-dyn.isp.belgacom.be
1246704818 Q * ktwilight Ping timeout: 480 seconds
1246705288 Q * fback Read error: Operation timed out
1246705985 J * fback fback@red.fback.net
1246709142 N * DoberMann[ZZZzzz] DoberMann
1246709724 J * ktwilight__ ~keliew@158.244-64-87.adsl-dyn.isp.belgacom.be
1246710109 J * saulus ~saulus@c135031.adsl.hansenet.de
1246710131 Q * ktwilight_ Ping timeout: 480 seconds
1246710185 J * ktwilight_ ~keliew@173.84-240-81.adsl-dyn.isp.belgacom.be
1246710550 Q * ktwilight__ Ping timeout: 480 seconds
1246710840 J * docelic__ ~docelic@78.134.196.188
1246711246 Q * docelic_ Ping timeout: 480 seconds
1246711539 J * dna ~dna@128-205-103-86.dynamic.dsl.tng.de
1246711740 N * Bertl_zZ Bertl
1246711743 M * Bertl morning folks!
1246711834 M * Bertl mxs_: no, Linux-VServer and ext4 hasn't been tested yet (at least not by us)
1246712055 M * Bertl mxs_: but if you get a kernel trace, and you have reason to believe that the problem is in the Linux-VServer code, uploading that trace is the first step to get it fixed :)
1246712224 M * Bertl arachnist: what's the problem with booting? any bootup logs to look at?
1246712359 M * mxs_ Bertl: I am not 100% sure what the cause is yet, trying different combinations and kernel configs to close in on it
1246712391 M * mxs_ right now I'm trying your patch to 2.6.29.2 + vserver + grsec. The bug gets triggered only with grsec present, and it might very well be that I suck at integrating 2.6.29.5+vserver+grsec ;)
1246712443 M * Bertl so, with 2.6.29.x + Linux-VServer everything is fine?
1246712445 M * mxs_ Bertl: but you should fix that flag I mentioned, 1<<24 is already used
1246712452 M * Bertl (except for the flag issue, yes)
1246712456 J * fback_ fback@red.fback.net
1246712456 Q * fback Remote host closed the connection
1246712464 M * Bertl I changed that to <<30 in my tree
1246712482 M * Bertl (a few minutes ago :)
1246712482 M * arachnist Bertl: it's xen related. without xen patches, the kernel booted fine.
1246712485 M * mxs_ with 2.6.29.5 + vserver itself, the bug is not triggered. I am not 100% sure whether that is because there is no bug, or whether that is because grsec is not croaking about it (it mentions refcount issues)
1246712520 M * mxs_ Bertl: might I suggest you change it to 0x20000000 or something the like ? That way it would be immediately obvious if the flag gets taken over by regular ext4 folks, as well ;)
1246712522 M * Bertl i.c. maybe check with harrydg_ then?
1246712532 M * arachnist Bertl: the xen loaded, screen got blank and machine rebooted itself
1246712553 M * Bertl serial console logs?
1246712558 M * arachnist hmm
1246712578 M * arachnist haven't though about that
1246712595 M * arachnist will try when i get home
1246712600 M * mxs_ ok, it's definitely not just my patching-ineptitude
1246712612 M * mxs_ your 2.6.29.2 + vserver + grsecurity exhibits the same behavior
1246712633 M * Bertl 'your' means, the combo harry does, right?
1246712642 M * mxs_ I mean the one that is on the vserver webpage ;)
1246712661 M * mxs_ so if that is harry's, then yes
1246712672 M * Bertl yeah, that one, there is no official Linux-VServer + grsec integration
1246712699 M * Bertl but in this case, it should be easy to check what changes are done to the ext4 code, no?
1246712706 M * mxs_ well, there is no official vserver 2.3 either, just experimental ;)
1246712732 M * mxs_ I am not 100% sure whether it will only happen on ext4. That is the next thing to test. Rebooting and putting that same vserver on ext3 :)
1246712755 Q * fback_ Remote host closed the connection
1246712758 M * arachnist Bertl: btw, any reason why there aren't any official linux-vserver patches for post 2.6.22 kernels?
1246712759 M * mxs_ (and I will try to get the first stacktrace I got in a sec; there are thousands of em once I let dbench loose inside a vserver)
1246712768 M * Bertl mxs_: the 2.3.x patches are official, as you said, experimental, what you mean is, there is no stable release for recent kernels :)
1246712782 M * arachnist s/official/non-experimental/
1246712795 M * arachnist (on my sentence)
1246712831 M * Bertl arachnist: because there is nobody to do extensive testing required for a devel or stable release ... (last financial contribution was more than a year ago)
1246712833 J * fback fback@red.fback.net
1246712848 M * arachnist oh, i see
1246712854 M * mxs_ Bertl: well, http://linux-vserver.org/Downloads does not make a distinction between non-grsec and grsec downloads other than that they are in different columns of the table; if that's not official, somebody should probably mention it on the official download page ;)
1246712868 J * ktwilight__ ~keliew@136.7-240-81.adsl-dyn.isp.belgacom.be
1246712905 M * Bertl mxs_: feel free to add a statement there .. 
1246713186 M * mxs_ not easy to get the initial stacktrace. It appears I get so many of them that klogd gets em all mangled.
1246713194 M * mxs_ I only get the last one in clear order :/
1246713206 M * Bertl you need the first one, get a serial console
1246713275 M * mxs_ is this any use at all : http://pastebin.com/m49c83d80 ?
1246713284 Q * ktwilight_ Ping timeout: 480 seconds
1246713287 M * mxs_ heh, I'd love to, but I do not have physical access to that machine :)
1246713295 M * mxs_ well, gonna test it on ext3 now
1246713345 M * mxs_ would a serial console not suffer from the same problem ? it is a round robin buffer IIRC :)
1246713370 J * ktwilight_ ~keliew@164.161-247-81.adsl-dyn.isp.belgacom.be
1246713372 M * Bertl you can extend the buffer, but usually it is large enough by default
1246713505 M * mxs_ it appears only to happen inside the vserver too, outside it I cannot trigger it (i.e. even thrashing hte system with dbench 500; although dbench might just not be enough ;)
1246713577 M * mxs_ not ext4-specific. I get it in ext3 too.
1246713647 M * Bertl okay, try to recreate it without grsec then
1246713654 M * mxs_ unable to.
1246713675 M * Bertl good, then check what code pathes are affected by the grsec patch
1246713694 M * Bertl in ext3/ext4 (I presume it will be very similar code)
1246713698 M * mxs_ (this is with the patch linked on the vserver download page; I wonder whether harry could test it as well :)
1246713735 M * mxs_ at this point I am not sure it is ext3/ext4, could be in the vfs layer as well. vserver and grsec touch some similar things.
1246713737 M * Bertl harry does basic testing, but is mainly event driven ... i.e. if some issue is reported, it will be investigated
1246713765 Q * ktwilight__ Ping timeout: 480 seconds
1246713945 M * mxs_ so far, I can trigger the bug on demand with debian lenny, 2.6.29.2 + vserver + grsec patch as linked from vserver download page, with a rather minimal lenny guest (debootstrap-generated) running dbench 1 (or dbench 10 for a quicker result) inside the vs;
1246713973 M * mxs_ machine is a nehalem core i7, x86-64 debian, 8g ram
1246713988 M * Bertl did you try with grsec disabled but patched in?
1246714007 M * mxs_ gonna have to try to replicate it in a vmware at home on a different architecture soon, but for now I need to get the kernel working somewhat stably so grsec will have to wait :/
1246714011 M * mxs_ not yet, I can try
1246714013 M * mxs_ sec
1246714112 M * mxs_ gotta wait till the machine comes back up and then recompile, will take about 10 min
1246716106 Q * bonbons Quit: Leaving
1246716914 M * mxs_ no oops or traces with all grsec config options disabled
1246716924 M * mxs_ gonna try to figure out which one is the culprit
1246718034 Q * Mr_Smoke Remote host closed the connection
1246718036 J * Mr_Smoke smokey@layla.lecoyote.org
1246719878 M * mxs_  CONFIG_PAX_REFCOUNT
1246719916 Q * dna Quit: Verlassend
1246719958 M * Bertl so ..check for that then, and look for branches or references 
1246720075 J * geb ~geb@212.4.82-79.rev.gaoland.net
1246720233 M * mxs_ well, it's either because grsec's refcount checker is patched together wrongly, or vserver is overflowing refcounters. But this is something I will have to evaluate later, since the system this is all happening on is supposed to actually be used next week, and I am not done with the jail setups yet :)
1246720269 M * Bertl well, you ar eprobably more than fine without grsec
1246720313 M * mxs_ ... must ... resist ...
1246720335 M * mxs_ <sarcasm> in code where 1<<24 == 0x1000000 is a problem ? :-P
1246720361 M * mxs_ yeah, one is "probably" fine, but grsec has saved my hide once before (or rather one of its features did)
1246720361 M * Bertl if you are using ext4, change it to <<30
1246720375 M * mxs_ I changed it to 0x20000000
1246720384 M * mxs_ since I am 100% sure no other flag in that file uses that :>
1246720388 M * Bertl should be fine too
1246720433 M * mxs_ I intend to try playing with chroots inside vservers as well, so grsec is somewhat mandatory in that case
1246720494 M * Bertl how so?
1246720594 M * mxs_ almost all the "common" ways to break out of chroots are blockable with it
1246720648 M * Bertl well, why not use a guest environment for that, if you plan on arbitrary execution?
1246720686 M * mxs_ granted, processes inside the chroot inside the vserver should not be running as root, and the chroot-environment should not make it possible to elevate -- but IMHO it is better to have too many barriers than too few
1246720734 M * mxs_ it's the more paranoid mindset, I know
1246720786 M * mxs_ but one could then ask the same question for "why use chroot in a vserver", then "why use vserver when chroot would do", then "why use chroot when unix permissions work", etc.
1246720836 M * Bertl you forgot my question on top of that, why us chroot if there is Linux-VServer :)
1246720842 M * Bertl *use
1246720893 M * mxs_ I like to think of vserver as chroot on steroids :P
1246720909 M * Bertl yeah, so why not use it for your chroot purposes?
1246720996 M * mxs_ now this is where it gets tricky. Let's say I would like to run apache httpd as user A, and give each vhost's dynamic code individual users (usually via WSGI or FastCGI or plain old CGI invocation, all of which usually work by way of suexec).
1246721005 M * julius hehe
1246721027 M * julius that's pretty close to the use case I set up chroots in a vserver :)
1246721029 M * mxs_ I know how to get httpd + suexec(patched with chroot and some sugar) + FastCGI working in a reasonably fast, reasonably secure manner
1246721040 M * arachnist Bertl: btw, would it make sense for vserver to use the *-namespace kernel thing?
1246721061 M * daniel_hozac we do.
1246721065 M * arachnist oh
1246721072 M * Bertl arachnist: Linux-VServer is using the *-namespace thingy for a long time now :)
1246721079 M * mxs_ I have not explored the performance impact or implications of using vserver syscalls to cross the barrier in suexec.
1246721109 M * arachnist i should've looked at the code before asking that question
1246721160 M * mxs_ julius: my (vserverless) setup is explained on http://e.metaclarity.org/, though that's more of a howto for people who kept asking :>
1246721266 M * mxs_ Bertl: so is it easily possible to do something akin to "vserver blah enter" with really limited code running suid and only well-defined barrier-crosses (by way of the std/err pipes, basically) ?
1246721284 M * mxs_ I might look at that in the future, could be interesting to use in a vhosting environment with "fat" user directories
1246721314 M * mxs_ (but not individual httpd instances inside vservers, since that can become really quite wasteful)
1246721316 M * Bertl yes, that is quite simple, but it might get a hell of pre-setup
1246721364 M * Bertl i.e. creating contexts for each user (either on the fly or at startup)
1246721406 M * Bertl you also need to adapt the patch to this setup a little, so that you are allowed to migrate between contexts
1246721421 M * mxs_ yeah, it is a bit fattier than plain 'ole chroot
1246721470 M * Bertl but it might already suffice to create a namespace and do the pivot thingy util-vserver does
1246721488 M * mxs_ as said, I have not looked at it in detail; a chroot setup works for most cases (proc-handling sucks, but other than that it is pretty usable even for shells)
1246721528 M * mxs_ I just gave that answer since you asked "why not vserver instead of chroot" :P
1246721542 M * Bertl fair enough :)
1246724280 N * DoberMann DoberMann[PullA]
1246724377 J * doener ~doener@i59F5A7EF.versanet.de
1246724480 Q * doener_ Ping timeout: 480 seconds
1246724868 M * Bertl nap attack ... bbl
1246724874 N * Bertl Bertl_zZ
1246727744 J * cehteh ~ct@pipapo.org
1246729588 J * hparker ~hparker@2001:470:1f0f:32c:290:96ff:fe50:40fa
1246731086 J * ktwilight__ ~keliew@240.15-240-81.adsl-dyn.isp.belgacom.be
1246731086 Q * ktwilight_ Read error: Connection reset by peer
1246731397 Q * ktwilight__ Read error: Connection reset by peer
1246731444 J * ktwilight__ ~keliew@241.66-65-87.adsl-dyn.isp.belgacom.be
1246732187 J * hijacker_ ~hijacker@87-126-142-51.btc-net.bg
1246732304 Q * geb Quit: /
1246732522 J * cga ~weechat@82.84.186.173
1246732606 Q * cga 
1246733861 J * Snow-Man_ ~sfrost@tamriel.snowman.net
1246733875 Q * Snow-Man Read error: Connection reset by peer
1246735658 Q * ktwilight__ Read error: Connection reset by peer
1246735768 J * ktwilight__ ~keliew@239.55-240-81.adsl-dyn.isp.belgacom.be
1246735849 N * Bertl_zZ Bertl
1246735854 M * Bertl back now ...
1246736094 Q * Mr_Smoke Remote host closed the connection
1246736118 J * Mr_Smoke smokey@layla.lecoyote.org
1246736378 M * fback good evening, bertl
1246736391 Q * hparker Quit: Read error: 104 (Peer reset by connection)
1246736452 M * fback how's your relocation?
1246736777 J * bonbons ~bonbons@2001:960:7ab:0:2c0:9fff:fe2d:39d
1246737247 M * mnemoc relocation?
1246737308 M * Bertl well, we moved a year ago, so that can be considered complete by now :)
1246737343 M * Bertl unfortunately the old house is still not sold ...
1246737360 M * mnemoc :(
1246737364 M * fback world crisis ;)
1246737928 M * fback Bertl: you've moved from a house to 13th floor? ;-)
1246737955 M * Bertl nah, virtually I've always been on the 13th floor :)
1246737969 M * Bertl btw, if you don't know the movie, it's worth watching ...
1246738412 Q * bonbons Quit: Leaving
1246738547 M * fback Bertl: the one from Josef Rusnak?
1246738685 M * Bertl yep, with armin mueller-stahl and gretchen mol
1246738769 M * fback I think I heard of it
1246738785 M * fback it was about some place with 12th and 14th floor
1246738791 M * fback some firm iirc
1246738820 M * fback but haven't seen the movie
1246739809 Q * urbi Read error: Connection reset by peer
1246740586 J * dna ~dna@128-205-103-86.dynamic.dsl.tng.de
1246742676 Q * xdr_ Ping timeout: 480 seconds
1246745463 Q * dna Quit: Verlassend
1246747605 Q * arachnist Remote host closed the connection
1246747608 J * arachnist arachnist@smierc.net