[00:15] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [00:18] netrose (~john877@cc-ubr03-24.171.20.14.charter-stl.com) left irc: Ping timeout: 483 seconds [00:18] Simon (~sgarner@apollo.quattro.net.nz) left irc: Read error: Connection reset by peer [00:19] Simon (~sgarner@apollo.quattro.net.nz) joined #vserver. [00:34] Nick change: Bertl_oO -> Bertl [00:36] hello to all ... [00:36] hey Bertl [00:37] what's up jon? [00:42] hi Bertl, 2.4.22-c17h with util 192 works fine :) [00:43] good to hear ... this was on x86_64 yes? [00:44] yes [00:45] thanks for testing ... [00:46] Simon: can you please try to compile 0.23.194 in x86_64? [00:46] Ok [00:46] there is lots of dark magic for this -fPIC thing [00:47] are you interested in becomming our 'official' x86_64 vserver tester? ;) [00:48] any opinion on having ->virtual_context and ->namespace bound to each other ? [00:48] what is the recommended way to declare/use new syscalls? Declaring them with _syscallX(...), or using syscall(2) with varargs? [00:49] Bertl, yes but this machine will need to go into production in a couple of weeks [00:50] riel: can create some vulnerabilities: to mount filesystem, you have to enter context with a CAP_SYS_ADMIN process. processes in the context can ptrace it and can gain this caps also [00:51] ensc: in 2.4 yes [00:51] ensc: in 2.6, with the LSM framework, we might be able to be more flexible [00:53] Nick change: Bertl -> Bertl_oO [00:55] riel: when you can do this with LSM, this virtual_context <-> namespace bounding sounds ok. [00:55] for example, look at sys_sethostname() in kernel/sys.c [00:55] the permission check there is CAP_SYS_ADMIN [00:56] riel: I do not know enough about LSM, to say if this is secure [00:57] riel: I would prefer some additional namespace-features like entering the namespace of foreign processes [00:57] for 2.6 vserver, we could change sys_sethostname() to modify ->virtual_context->hostname [00:57] instead of the physical host hostname [00:57] ensc: you're right, processes must be able to enter [00:57] that's indeed not possible with the current fs namespace infrastructure [00:58] we'll need to add that somehow [00:58] ... OTOH ... why exactly do processes need to transfer between virtual contexts ? [00:58] I haven't yet heard of a reason why this is needed [00:59] riel: e.g. to kill a context you have to enter it [00:59] (and kill all its processes) [01:00] any other uses ? [01:01] riel: handling is much more easier; without this feature, you would have to start a ssh-daemon in each context [01:02] good point [01:02] ok, so we need to enter virtual contexts namespaces from the "root" context [01:02] we just don't need the ability to go from one namespace to another [01:03] I would like a hierarchical concept [01:03] (to enable vservers in vservers) [01:03] mmmm ok [01:04] that makes sense [01:04] and I would remove this special ctx-1 [01:04] they don't need to be hierarchical, some just need to have "control permissions" over other [01:04] s [01:04] riel: ok; a tree structure was my first thought since it is easy to implement [01:05] but agreed, you want a customer to be able to control his/her vservers [01:05] *nod* [01:05] a tree structure is fine with me [01:05] or just virtual_context->parent ;) [01:05] riel: yes, a parent-pointer is enough [01:06] a child[] array/list is not needed, IMHO [01:06] not needed period ;) [01:06] it's simple to walk the ->parent->parent->... chain [01:07] so change_context(ctx1, ctx2) can walk the parent chain for ctx2 and only allow the operation if ctx1 is a parent [01:07] yes [01:08] some limitations are probably required when creating new contexts (max tree-depth, or max child-contexts) [01:09] "cannot create new context without permission from root" ? [01:09] mmmm damn, there's a problem [01:10] riel: no, call 'set_maxchildren(int)' which can decrease current number only [01:10] nono, I mean, how do you make sure that a vserver cannot create a new vserver with the virtual_context ID of a vserver outside of itself ? [01:12] what would be the use of vservers within vservers? [01:12] just out of curiosity ;) [01:12] first: look into list of contexts, if ctx already exists. If not -> ok. If yes -> check if parent [01:12] Simon: a customer could have multiple virtual hosts on your server farm [01:13] Simon: and be able to manage those from a "control virtual server" [01:13] Simon: e.g. the new Fedora Buildsystem will use vservers-in-vservers probably [01:13] ahh nice [01:15] JonB (~jon@kg232.kollegiegaarden.dk) left irc: Quit: zzzzzzzzz [01:19] grrrrrrr [01:19] that might force me to implement things in selinux [01:20] instead of a nice and simple vserver lsm module [01:20] actually ... might be simpler than that [01:20] vserver ID could consist of two parts [01:20] "value" and "mask" [01:20] like an IP netmask [01:20] then it's easy to figure out if a vserver should be allowed to control another [01:20] ;)) [01:22] riel: how that? Check if 'value & mask' of two IDs are matching? [01:23] riel: your LSM module would not have information, which contexts are in use already? [01:24] context IDs should be stable across reboot [01:24] riel: you could replace the 'look into list of contexts' parts which: 'iterate through list of processes and check if their ctx-id matches the new one' [01:24] because of filesystem quotas [01:25] riel: or is it impossible for LSM modules to lock process creation/removal (which would change list of processes)? [01:26] I don't know, but I suspect it's possible just fine [01:27] riel: yes, you could spinlock the context-creation [01:27] what would that help ? [01:28] I haven't looked at how the per-context disk quota patch works [01:28] but obviously _something_ needs to be persistant across reboots [01:28] mmmm you're right, the virtual context ID doesn't need to be persistant [01:29] cool [01:29] you would prevent races (process A tries to enter context 'a', kernel goes through process-list and checks if 'a' is already in use; in meantime process B tries to enter 'a' also and is a little bit faster and 'A' gets the wrong result ('a' is free)) [01:29] btw, you don't go through the process list [01:30] I'd simply have a list of virtual contexts [01:30] riel: this was my first idea, but you said that would require more than a 'nice and simple vserver lsm module' ;) [01:30] it might still be possible ;) [01:32] btw, I think I'm not going to do a "int s_context" in the task struct [01:33] instead a "struct virtual_context * s_context" [01:33] riel: sounds good [18:20] loger joined #vserver. [18:28] morning [18:29] bert! [18:30] evening :) [18:30] hi Alex [18:30] ;) [18:31] mhepp (~mhepp@r72s22p13.home.nbox.cz) left irc: Ping timeout: 483 seconds [18:31] Hi Nesh :) [18:41] hello [18:42] hi matt [18:44] Hi matt [18:58] loger joined #vserver. [18:58] heh [18:58] how many clients you have now? [18:59] uhm [18:59] 59 VDS's currently running [19:00] for me fast day :) [19:00] awesome, I have a conference call with virtuozzo today [19:01] gonna try to work em down? [19:01] they are just too expensive [19:01] plus I like tinkering too much [19:02] and my control panel is nearing version 1.0 functionality [19:04] Matt you don`t install patch for log inodes with errors ?