[00:01] bertl you were part of the split [00:01] ah, okay ... that explains it ... [00:01] Quit (uranium.oftc.net keid.oftc.net) [00:03] Doener_zZz (~doener@pD9E12F73.dip.t-dialin.net) got lost in the net-split. [00:03] JonB (~jon@129.142.112.33) got lost in the net-split. [00:03] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) got lost in the net-split. [00:12] Hi Bertl! [00:22] ensc: would you be so kind and verify my signed md5sums for 1.00, 1.22 and 1.3.3? [00:24] Bertl: thx, they are matching with my copy... [00:25] wonderful ... [00:26] your gpg key is not really trusted, but I have more headache about the other, still undiscovered flaws in the kernel :( [00:27] hmm, why is my key not really trusted? [00:29] everybody could create a key with the name 'Herbert Poetzl', kidnap the real Herbert Poetzl and go with his identity into the IRC to convince people to use his backdoored (but signed) patches ;) [00:35] hmm, okay but who are you? [00:37] hehe [00:38] Action: irmin wants rmap for 2.4.23 [00:39] go ahead, bug Master Riel ;) [00:39] he is bug-protected :) [00:39] Action: irmin . o O ( by exec-shield? ;) ) [00:51] okay enrico, let me know when you are ready to get some work done ... [00:57] MrBawb (abob@swordfish.drown.org) left irc: Quit: kernel upgrade [00:58] Bertl: work for the new syscalls in 1.3.3? [00:58] hmm, well yes, and soem stuff for the next generation ... [00:59] I will see what I can do, but the rest of today is reserved for other tasks [01:00] okay, we need to talk about the 'new' procfs for vserver too ... [01:05] infowolfe: still looking for xfs support? [01:08] MrBawb (abob@swordfish.drown.org) joined #vserver. [01:16] nathan_ (~nathan@209-6-130-26.c3-0.sbo-ubr1.sbo-ubr.ma.cable.rcn.com) joined #vserver. [01:17] Bertl, any reason i wouldnt want to restrict access to virtual outside of the main context? [01:18] huh, what? you mean the procfs ... yes, this will be protected ... [01:18] Bertl: btw, should I replace all IS_IMMUTABLE calls to IS_IMMUTABLE_FILE in xfs/* ? [01:18] irmin: which kernel? [01:18] yea the procfs sorry [01:19] Bertl, seems i can limit my risk of the race conditions by just keeping it in the main server for now [01:19] hmm .. [01:20] Bertl: 2.4.23-xfs [01:20] Bertl: (updated to .24 but it doesn't matter) [01:21] hmm, well, wasn't xfs included in 2.4.24? [01:21] Bertl: .24 have only 2 security and 2 oops fixes [01:21] I mean 2.4.23 ... sorry ... [01:21] Bertl: no, no built-in xfs [01:22] ah right ... there was a long discussion but no inclusion ... ck1 does include it though ... [01:23] hmm so you are too interested in xfs support, right? [01:24] Bertl: well, I already did such patches for previous kernel builds (.20 and .21) :) And it even worked :) [01:25] yeah, it's great you did that ... ;) (basically it should boil down to 2-3 modifications of IS_IMMUTABLE and the according flags) [01:26] but I just discovered that the ck1 releases I made do not support xfs ... [01:27] which in turn means that I have to fix this anyway ;) [01:27] Bertl: I'll tell you if the debian-adopted .24 kernel with vserver will bootstrap correctly soon :) [01:27] so you can save your time and efford, and wait for the ck1 fix ... and just use/adapt that one ... [01:28] ck1? I do not use ck patches.. [01:28] yeah, but it includes xfs, and you use xfs ... [01:28] Mister_A_ (~mab@pool-141-155-130-201.ny5030.east.verizon.net) joined #vserver. [01:28] Hi all [01:29] hi Mister_A_! [01:29] If im running 2.4.23-vs1.22 #5 SMP, should I assume im vulnerable to todays root exploit? [01:29] Bertl: it is compiles already :) [01:29] Mister_A_: yup, as it affects 2.4.23 ... [01:29] Mister_A_: get 2.4.24 patch on kernel.org and apply it ontop of .23 sources. It should apply cleanly [01:30] do i have to run the vserver patch again after that? [01:30] or get the vserver patch for 2.4.24 ;) [01:30] i like you're idea better :-D [01:30] do i have to recompile the kernel after I apply the patch? [01:30] if you want to use it, yes ;) [01:31] i shoudl jsut download patch-2.4.24-vs1.22.diff and apply it to my current 2.4.23 source tree? [01:32] nope, to a vanilla 2.4.24 kernel, or what patchset you use ... [01:32] _shuri (~shushushu@vserver.electronicbox.net) left irc: Ping timeout: 483 seconds [01:32] but you could do as irmin suggested, and patch the 2.4.23-vserver up to 2.4.24 with the 2.4.24 patch [01:33] it won't apply cleanly because of the version issue in the toplevel Makefile ... but it should work [01:34] so im gonna download the 2.4.24 kernel from kernel.org [01:34] and then apply patch-2.4.24-vs1.22.diff.bz2 [01:34] then compile [01:34] is there a way to use the same config files as i sued for 2.4.23 (ie to enable my 3ware raid, and network cards etc) [01:34] yeah, probably copying over your .config file from the old kernel, and doing make oldconfig would help [01:36] Bertl: yeah, I'm usually don't count top-level Makefile rejects as rejects :) [01:36] thanks so much for your help. [01:37] ill try the new kernel tomororw am when im available to drive to the DC incase of failure :) [01:38] sure, you can compile it today, setup everything and boot it tomorrow ... [01:38] ive been using this lilo -d option that will boot the new kernel only the next time it boots, and then i pass panic=15 so it reboots after 15 seconds, so if there is a kernel panic it will reboot and resort back the good kernel [01:39] but the catch is, sometimes the new kernel loads, but the network drivers dont so the kernel and machien are up but the network is done :( [01:39] Mister_A_: use serial console for such things [01:40] ya, but im not at the DC to hook it up :( [01:40] im thingin of buying a 32 port kvm and then 1 kvm over IP [01:40] going to eat [01:40] ill be back [01:44] tanjix (ViRu_@pD9049D9F.dip.t-dialin.net) left irc: [01:47] could i apply the VS patch before or after i copy the old .config file over [01:48] *should* [01:49] doesn't matter, but when you do the make oldconfig, the kernel should be in the final state .. [01:51] ok running make oldconfig :-D [01:51] now make dep? [01:52] make dep >../Dep.log [01:52] make bzImage modules >../Build.log [01:52] this way you only get the warnings/errors ... [01:53] acsi.c:74:25: asm/atarihw.h: No such file or directory [01:53] acsi.c:75:27: asm/atariints.h: No such file or directory [01:53] acsi.c:76:28: asm/atari_acsi.h: No such file or directory [01:53] acsi.c:77:29: asm/atari_stdma.h: No such file or directory [01:53] acsi.c:78:29: asm/atari_stram.h: No such file or directory [01:53] alot of those type errors [01:53] i2c-algo-sibyte.c:32:30: asm/sibyte/64bit.h: No such file or directory [01:53] i2c-algo-sibyte.c:33:36: asm/sibyte/sb1250_regs.h: No such file or directory [01:53] i2c-algo-sibyte.c:34:37: asm/sibyte/sb1250_smbus.h: No such file or directory [01:53] md5sum: WARNING: 1 of 13 computed checksums did NOT match [01:53] rtc.c:27:25: asm/machdep.h: No such file or directory [01:53] rtc.c:29:22: asm/time.h: No such file or directory [01:53] via-pmu.c:36:22: asm/prom.h: No such file or directory [01:53] via-pmu.c:37:25: asm/machdep.h: No such file or directory [01:53] via-pmu.c:41:26: asm/sections.h: No such file or directory [01:53] via-pmu.c:44:30: asm/pmac_feature.h: No such file or directory [01:53] stop stop, we know them ... [01:53] sorry [01:53] are those normal? [01:53] yup [01:54] 53c700.h:40:2: #error "Config.in must define either CONFIG_53C700_IO_MAPPED or CONFIG_53C700_MEM_MAPPED to use this [01:54] scsi core." [01:54] usually they pass by, lost in the amount of information, and you do not even notice them ... [01:54] ok [01:54] runing bzImage and modules [01:54] do i have to do modules_install ? [02:01] if you use modules, yes ... [02:25] Bertl, 2.4.24-ck1-vs1.3.3-grsec-nc is rather solid [02:25] Bertl, i havent stressed /proc/virtual/* though, intentional. [02:26] yeah, keep it so, untill we have the next gen procfs ... [02:26] k im gonna put it on a production box, ill just make /proc/virtual only or main [02:27] sounds good by the way, I hope the grsec and what's nc? is available and linked from linux-vserver.org ;) [02:27] i havent run this in production since ctx17, wee [02:27] Bertl, nc is my netconsole patch [02:27] Bertl, i used the grsec patch from the ck1 site [02:28] it all required some hand patching to get it to blend though [02:28] Bertl, want me to link this stuff on the wiki? [02:28] yeah sure ... [02:29] which grsec version is this? [02:30] 1.9.13 [02:35] Mister_A_ (~mab@pool-141-155-130-201.ny5030.east.verizon.net) left irc: [02:38] Bertl: is it a known issue that 'fakeinit' does not work with a static ctx? [02:38] hmm, not for me ... [02:38] chcontext --ctx 345 --flag fakeinit cat /proc/self/status | grep initpid [02:38] initpid: 0 [02:39] # chcontext --flag fakeinit cat /proc/self/status | grep initpid [02:39] initpid: 839 [02:39] but I remember some reports that fakeinit isn't working ... [02:39] let me check, which kernel patch? [02:39] 1.22 [02:40] hmm, cool ... [02:41] it works in 1.3.3 ... [02:42] I'll add that test to my test script, and search for the bug in 1.22 [02:42] ok thx, but I will not upgrade my servers to 1.3.3 ;) [02:43] hmm, this is in 1.00 too ... [02:44] I never used static ctx's before... but you suggested to do so [02:45] heyda, are you sure it ever worked? [02:46] ctx-17 on 2.4.21 gives the same results ... [02:46] it seems that the 'old/original' code is faulty in this regard ... [02:47] dunno, I tried static ctx + fakeinit this weekend the first time [02:48] hmm looks like we'll do a 1.23 bugfix release soon ... [02:54] how can I try to boot new kernel in grub but have it to load standard kernel in the case of failure? (like lilo -d) [02:55] lilo -R, but I don't know a way to do that ... [02:55] echo 'savedefault --default=0 --once' | grub --batch -- [02:56] don't ask why... I do not know it... ;) [02:56] (it's a RH patch) [02:56] upsi dupsi, is that documented somewhere? [02:56] not the '--once' [02:57] fedora-devel had some discussion about it in the last days [02:57] looks like this feature sneaked in around 0.92 ... [02:57] https://listman.redhat.com/archives/fedora-devel-list/2003-December/msg01692.html [03:01] ah okay, live and learn ... never thought of that ... [03:01] finally it all makes sense ... if somebody needs an explanation, why it works, jsut ask me ;) [03:02] it have "fallback" parameter.. [03:02] but be careful, this seems to 'remove' the default setting for grub 0.93 [03:03] isn't an issue if your first entry is your default ... [03:06] so actually the command should be echo 'savedefault --default=1 --once' | grub --batch -- [03:06] and the default should be 0 i guess ... [03:36] hmm enrico if you find some time, think about the procfs and how it should look like for your tools (regarding vserver) ... [03:38] I need a way to determine if a context is still alive (there is needed some kind of state, e.g. create -> running -> killed -> (removed)) [03:38] I would prefer a syscall for that [03:39] hmm, okay, something like 'locate context xid'? [03:39] or vc_getstat()? [03:40] latter [03:41] or would a enter_context() syscall which fails if the context doesn't exist be sufficient for your purpose? [03:43] the problem is, when it succeeds... I would have to do everytime special preparations (e.g. chroot, ulimit, ...) when doing this [03:44] else, a malicious process in the ctx could ptrace me and gain privileges [03:44] well, the advantage would be, that it's kind of atomic ... [03:44] you can test a hundred times for ctx=100, and then when you try to enter it, it is gone ... [03:46] I just want to know if the ctx is still alive. E.g. I have 'kill 15; sleep 5; kill 9' sequences when shutting down a vserver. The sleep and following 'kill 9' can be omitted when vserver is dead [03:48] ah okay .. but that actually is a trusty assumption, because just in the moment you check, somebody enters the context ... [03:49] I thought about an option to 'shutdown' or 'lock' a context before it is removed ... [03:50] ok; good idea [03:51] maybe a predefined state engine, which only allows to do the following cycle: [03:51] create - setup - start - stop - destroy [03:53] this way, we could move the kill -9 to the kernel ... [03:55] I do not know if it really a good idea to request such an explicit destruction [03:56] was just _an_ idea ... [03:59] I would really like a functionality like wait4() which returns statistics (CPU usage, ...) about the diedvserver [04:00] hmm, possible, but you have to 'attach' to the 'context' in this case ... [04:01] unless you split the 'creator' into two halves, one becoming init and the other waiting for it to die ... [04:03] why not '... -> stopped/locked -> (xid entry still existing) -> wait (-> cleans ctx-information)' [04:04] that was what I meant with 'attaching' [04:05] the question is, is there data which will be the result of a context exit, or would that just be the xid entry in it's least recently updated state? [04:05] I do not know how resources are counted in the kernel... [04:06] because in that case, we could get away with not removing the context info at all ... sitting and waiting there for an explicit removal ... [04:24] okay, so basically your tools will not require the proc interface per se, right? [04:27] no, I want to avoid /proc parsing [04:28] okay, you know that 0.27 does still query proc ... [04:28] I do not have another choice :( [04:30] hmm, okay so you need the 'get status of context xy' syscall command, right? [04:31] or is there anything else you need? [04:32] yes, but I am not sure about the semantic... with WNOHANG, it could return current resource usage; without WNOHANG, it could wait for its removal [04:32] a kind of polling wouldn't be sufficient for the moment? [04:33] Action: ensc hates polling [04:33] the issue is, this would require some waitqueue mechanism, I would like to avoid, unless extensively tested ... [04:34] mmh, ok. for the moment WNOHANG would be enough [04:35] okay, the next question is, what information do you want to retrieve with that syscall command? [04:35] I would like to have a way to store userspace-information (e.g. vserver-name) in the context... [04:36] maybe you could have a look at the current structures in 1.3.3 and make a suggestion [04:36] I need process-count, for other statistical information I do not have any use currently [04:36] there are some fields in the uts entry, which might come handy for that ... [04:37] uts modification is bad since it requires CAP_SYSADMIN [04:37] hmm, well you won't modify the context names without it? [04:38] vservers-in-vservers... ;) [04:38] by the way, for what do you need a context name? [04:38] e.g. for vps [04:39] the xid is unique, do some hash/lookup to set/get additional info [04:39] hash lookup to where? [04:40] if we 'introduce' a name for each context, the next thing that pops into my mind is, how to ensure that this name is unique, and why not change all syscalls to allow a name instead of a number? [04:41] whatever tool creates a vserver, should be able to associate a name with the xid, somehow ... [04:41] no need to make it unique... process-names can be ambiguously also [04:42] hmm, okay why not do this 'book keeping' in userspace? [04:48] it needs lots of management effort, requires an agreement about the place where these information are stored, can be disturbed by processes which do not follow these rules and split informations which are belonging together [04:49] hmm, but this is no good reason to put ldap into the kernel ;) [04:49] why ldap? a similar mechanism exists with processes already [04:51] hmm, okay so you want to 'add' a name to the context, which isn't changed while the context is living, and isn't reported back or used by any syscall, only the procfs, right? [04:51] or do you want that libc's execv() stores information about the arguments somewhere in /var, and ps reads them from there? [04:51] yes, procfs would be enough for this purpose [04:52] okay, if we pass this info on context creation, and it has some well defined length (about 16-64 chars) [04:52] I guess I can live with that ... [04:54] ok, that's fine with me [04:54] Bertl, any suggestions for a clean way to restore the visibility of /proc/virtual to the main context? [04:54] hmm, what is the issue there? [04:55] Bertl, nothing im just doing it for security precautions so there arent any stability issues [04:55] well I'm sorry I don't understand what exactly you are talking about, please elaborate ... [04:56] oh sorry [04:56] actually i think i know how i can do it easily but... [04:56] i want to make it so /proc/virtual access is restricted to ONLY the main server, not contexts. [04:57] for this purpose, there is the vx_permission() [04:57] this is actually one of my better ideas ;) [04:57] s/is/was/ [04:57] Bertl, ah [04:57] so my grep shouldnt be finding anything? [04:57] depends on how you set it up ... [04:58] basically every entry in /proc has two 'new' values ... [04:58] one is the xid, the other are the vx_flags ... [04:58] you know my vx_check()? [04:58] yea [04:59] okay, on every proc access, vx_check(xid, vx_flags) is done ... [04:59] yep i see that [04:59] xid and flags from the entry ... [05:00] so if you want an entry, that is accisble only from the HOST context ... just specify VX_ADMIN as flags ... [05:00] Bertl, so i will do this at the callback handler for the proc entry? [05:01] well, after the creation of /proc/virtual, you modify the vx_flags to VX_ADMIN [05:01] oh ok i see [05:01] easy enough [05:02] yeah, might be useful for /proc/mounts too ;) [05:03] does anybody know how jfs extended attributes are supposed to work? [05:20] hey Bertl, how stable is 1.3.3? [05:21] no xfs? [05:21] well I'm currently testing xfs ;) [05:21] and I guess xfs+ili is playing nice now ... after some bashing ... [05:22] ili? [05:22] Immutable Link(age) Invert ... [05:22] ah [05:22] would you like to test it, on xfs of course? [05:24] Bertl, i don't think i have a 2.4.24 xfs patchset :-\ [05:25] np [05:25] which means i have to wait on this machine anyway then :-p [05:25] I have 2.4.24-ck1 patch set ;) [05:25] because i can't do it without having an xfs kernel... [05:26] which includes xfs ... [05:26] Bertl, you can be sure that i'll probably be running ck1 [05:26] but again, i was attempting on that machine to go with 1.22 (stable) [05:26] MrBawb (abob@swordfish.drown.org) left irc: Ping timeout: 499 seconds [05:27] yeah, well 1.22 will not play nicely with ck1 ... because of the O(1) scheduler and other things ... [05:27] so i guess just don't worry about 1.22 [05:27] we just don't have a choice... [05:28] vs1.3.3 + ck1 on 2.4.24 is the only way to go at this point to get xfs AND linux-vserver [05:28] but I can assure you vs1.3.3 is pretty stable ... [05:28] not as stable as vs1.22 but ... I guess 2 more releases and we are on the finish line for 1.4 ... [05:29] s/finish line/home stretch/ [05:30] Bertl, will 1.4 be sane (1.4.x) or are you going to do the screwy 1.2x style with it? [05:30] yeah, I'm going to keep that screwy style ... [05:30] :-\ [05:30] how unsettling [05:31] hmmm [05:31] write_sysrq_trigger doesnt seem to check any sort of caps [05:31] oh maybe handle_sysrq does [05:31] infowolfe: but you are allowed to refer to 1.22 as 1.2.2, if you like to ;) [05:32] Bertl, the problem isn't with that, it's with grub :-p [05:32] Bertl, am i missing something or is sysrq_trigger a security issue inside of a context? [05:32] Bertl, can you give me an idea where to get the ck patches? [05:33] uhh? why grub? [05:33] I mean why is grub an issue, or why is it an issue for grub? [05:33] nathan_: hmm try it from within a context ... I never checked it ... [05:33] infowolfe, the ck patches are linked of linux-vserver.org [05:33] Bertl, it's an issue for me... having to think when copying configs over :-p [05:34] Bertl, where? [05:34] nevermnind [05:34] ah .. I see, well this would be totally different with lilo I guess ;) [05:34] Bertl, echo h > sysrq_trigger triggers the help inside of a vserver name enter with no extra caps [05:34] Bertl, it's a matter of vmlinux/vmlinuz naming [05:35] hey bertl? [05:36] umm, that link from the linux-vserver page has nothing to do with 2.4.24 [05:36] Bertl, would it be so unreasonable to force all write calls to /proc to a cap or strictly in the VX_ADMIN? [05:36] in fact, i'm not seeing any 2.4.24 patches on his site at all [05:36] infowolfe: 2.4.23-ck1 works well with 2.4.24 ... [05:37] ok [05:38] the vs1.3.3 patches are updated for 2.4.24 ... [05:39] Bertl, can you think of any case where a write to /proc would be done inside of a context? [05:39] thanks Bertl [05:39] nathan_: well, maybe all write to proc should be prohibited in vcontext ... [05:39] yea thats what im thinking [05:39] obviously nobody ever verified that ... [05:39] instead of having to poke around finding hazards/or having them introduced without notice [05:40] sysrq-trigger was new to me [05:40] let me finish the xfs stuff (about 5min) and we'll have a look at this issue ... [05:41] sure [05:42] hmm infowolfe: take a short break, I guess I'll release a new 1.3.4 in an hour or so ... [05:43] argh [05:44] AFTER i start the builds on 4 machines :-p [05:44] lol [05:44] sorry *hehe* [05:45] im sticking with 1.3.3 unless you have some fantastic or critical change :) [05:45] hey Bertl, would it be too hard for you to do a diff against the ck1-vs1.3.3 sources for a vs1.3.4 patch for me? (so i spend less time un-patching) [05:45] nathan_, it's mainly xfs related afaik [05:46] ah k no need for me then [05:46] nope, this is included in my service, called Incremental patches ;) [05:47] service? making me think i should figure out a way to pay you a salary Bertl, lol [05:47] ahh no problem, Ill give you my Bank Account number ... just a moment ,,, [05:47] lol [05:48] Bertl, let's see what happens with my "little lady" and me maybe moving to las vegas... [05:48] but you (all) should try to improve the kernel building procedure ... [05:48] if i get on there... and they fall in love with your software... it might just end up that they pay you for some customizations... (at my request) [05:49] Bertl, does 1.3.3 include q0 by default? [05:49] well, as long as the project stays free and everyone can make use of such customizations, I have no problem with that ... [05:50] the quota stuff isn't included, but no problem ... [05:50] hrm... since it seems to be included by default in the 2.4.24-ck1-vs1.3.3 [05:50] Action: infowolfe is going to go lay down for a moment [05:51] maybe ill start maintaining a grsec+ck1+vs+netconsole patch [05:51] Bertl, feel free to /msg me when 1.3.4 is out :-D [05:51] infowolfe: hmm, no only the vroot device is included ... [05:51] nathan_, mind if i ask what netconsole is? [05:51] nathan_: go ahead ... and write a howto, as I suggested, for netconsole ... [05:52] infowolfe, sends printks out the network [05:52] Bertl, yea [05:52] cool... [05:52] Action: infowolfe is lost [05:52] just trying to get my stuff sorted out before i take on anything extra [05:52] Action: infowolfe is going to lay down [05:52] infowolfe, combined with ipt_sysrq you almost have a serial console [06:07] sounds nifty [06:11] okay nathan, any ideas how to block the procfs writes? [06:13] nathan_: proc_file_write() would be a good start, I guess ... [06:15] hmm, could proc be mounted R0 ? [06:17] hehe, enrico? [06:17] ensc: we should make sure that proc for vserver is mounted ro ... [06:18] what do we gain from this? [06:18] well, did you try 'echo 1 >/proc/sysrq-trigger' recently? [06:19] or if you are bold, 'echo b >/proc/sysrq-trigger' from inside a vserver ;) [06:21] mmh, that would have saved me lots of time and I had not to dig for the do_brk() exploit... ;) [06:21] but are there any bad effects when /proc is read-only? [06:22] none I can think of ATM ... [06:22] we (you) should do an update on them tools ... what do you think? [06:30] Bertl, so was in the kitchen [06:30] Bertl, you are thinking mounting proc ro would do us? [06:30] did some fine cooking? [06:31] or just some fine eating ;) [06:31] beef jerky :) [06:31] tending to the beef hehe [06:31] Bertl, i did if (!vx_check(vx_current_id(), VX_ADMIN)) return -EPERM; [06:31] in proc_file_write but it didnt seem to catch it [06:32] hmm, well, that is actually a little superfluous ... [06:32] vx_check(0, VX_ADMIN) would be enough ... [06:32] Bertl, i just tested a remount,ro on the proc [06:33] but as I expected, many entries do not use this ... [06:33] works as expected [06:33] Bertl, yea, i was then thinking we wrap the write hook, but ro proc seems like a much cleaner solution [06:33] I guess enrico is still stunned by the fact, that a vserver host could go down so easily ;) [06:34] and nobody ever thought about it, except for you ... [06:34] mmh, this 'ro' attribute affects all /proc filesystems... [06:34] hmm, so ro once, means ro for all? [06:34] yep [06:35] guess we can fix this .. by faking the ro ... just what I wanted to hear ,) [06:36] afair, the sysrq kernel option is discouraged for secure systems [06:36] docu says 'Don't say Y [06:36] unless you really know what this hack does. ' [06:36] yeah, but what about limits? ever tried them? [06:37] which limits? [06:37] for example max processes [06:37] or max file handles ... are they safe? [06:37] (havent tried yet ;) [06:38] # echo 15000 >file-max [06:38] bash: file-max: Permission denied [06:39] they are covered by kernel caps [06:39] yea most are covered by the kernel caps [06:39] chcontext --ctx 100 echo "32768" > /proc/sys/kernel/shmmax [06:39] hmm forgot the secure ... [06:39] but wouldnt we be safe by just restricting the proc to ro in all the vservers by default? [06:40] what case does a vserver have where it needs to write to /proc? [06:40] yeah, and we do that ... [06:40] we make the RO flag depend on context ... [06:40] is that done by default in the scripts? or where? [06:40] later we can add a per context capability which weakens that ... [06:41] virtuoso (~shisha@ip114-115.adsl.wplus.ru) left irc: Read error: Connection reset by peer [06:41] no I mean, _we are going to do that_ right now ... [06:41] MrBawb (abob@swordfish.drown.org) joined #vserver. [06:44] oh ok [06:51] http://vserver.13thfloor.at/Experimental/proc_fix.diff [06:51] nathan_: try that one ... [06:53] k [06:55] hmm, seems not to work ... [06:55] I wonder why ... [06:57] ah works but only for mem/fd stuff ... [07:14]