[00:00] this sets up a rule and table for 192.168.0.x ... [00:00] @jack, oaky? [00:01] Yes [00:02] chbind --ip 192.168.0.2 ping -c 2 128.130.2.3 [00:02] works perfectly with this ... [00:02] chbind --ip 192.168.0.2 --ip 192.168.0.2 ping -c 2 128.130.2.3 [00:02] gives Network is unreachable ... [00:03] it took me some time to find the reason for this behaviour ;) [00:03] Interesting because ping is using raw packet and does not involve most of the code in the vserver [00:03] yes, but it uses connect() [00:03] I was not aware of that (ping using connect). I guess it does this to learn the output interface to use [00:03] and you have two different codepathes depending on the number of iproots ... [00:04] here a short printf debugging sequence ... [00:04] # chbind --ip 192.168.0.2 ping -c 2 128.130.2.3 [00:04] Yes one for a single IP, forcing this IP to be the source and one where the source is selected dynamcly, introduced in ctx-17a [00:04] ipv4root is now 192.168.0.2 [00:04] ЗЗЗ [z1] initial src=0.0.0.0 dst=128.130.2.3 [00:04] ЗЗЗ [a1] post src=0.0.0.0 dst=128.130.2.3 [00:04] ЗЗЗ [a2] post src=0.0.0.0 dst=128.130.2.3 [00:04] ЗЗЗ [a3] post src=192.168.0.2 dst=128.130.2.3 [00:04] ЗЗЗ [x1] src=192.168.0.2 dst=128.130.2.3 [00:04] ЗЗЗ [z2] final pre src=192.168.0.2 dst=128.130.2.3 [00:04] ЗЗЗ [z3] final post src=192.168.0.2 dst=128.130.2.3 err=0 [00:05] .. where in the second case ... [00:05] ЗЗЗ [z1] initial src=0.0.0.0 dst=128.130.2.3 [00:05] ЗЗЗ [a1] post src=0.0.0.0 dst=128.130.2.3 [00:05] ЗЗЗ [m1] ip_route_connect() ipv4root=192.168.0.2 [00:05] ЗЗЗ [m2] pre ip_route_output() src=0.0.0.0 dst=128.130.2.3 [00:05] the code checks if n>1 and then calls ip_route_output() [00:05] with the original src ... which fails for 0.0.0.0 ;) [00:06] and instead of using the first or second or whatever src for routing calculations, it simply fails ... [00:06] I don't understand. Using connect with src=0.0.0.0 is the standard way. Why is it failing for ping [00:06] this has severe inpact on how vservers 'calculate' the route ... [00:07] because there is no 'default' gateway, if the src address is 0.0.0.0 ... [00:07] Ok, you mean when you setup iproute2 with the special route for 192.168.0.0/24 ? [00:08] yes, this _is_ a problem if you want to have more than one network, with different default gateways ... [00:08] IIRC we had some reports on this ... and that it didn't work as expected ... [00:09] I understand. We are using ip_route_output to find the route so we can select the proper source IP, but this can't work [00:09] because it has to know the source IP before hand. How can this be solved ? [00:09] yeah, that is the problem ... [00:09] I was thinking about this, and I have two solutions ... [00:10] a) just 'define' that the first ip is the source in such cases, it would not matter anyway ... [00:10] ok, fallback to ipv4root[0] in all cases ? [00:10] b) try all defined IPs and take the first which succeeds ... [00:10] Ok. We would do the following [00:10] I'm not sure if the 0.0.0.0 test should be done anyway ... [00:11] try the current strategy. If it fails, picks each IP and find the one which works [00:11] 0.0.0.0 has to be done. the purpose is to find the best source IP. Unless you have special routing (per source iP) rule [00:12] hmm, how does the unmodified kernel decide this? [00:12] all source address are ok. I mean, I am allowed to send 192.168.0.2 address on 192.168.1.0/24 network. This is valid. [00:12] It uses ip_route_output as well with 0.0.0.0 [00:13] hmm ... yes, you are right ... haven't checked that before ... [00:14] we need per context routing tables! [00:14] Hum, I suspec that a ping may kind of fail as well even on a standard kernel with say two interfaces and two routing table, unless there is a default gateway [00:14] in the default route table. [00:14] yeah, checked this a few seconds ago ... [00:15] Its a chicken and egg problem [00:15] okay, what do you think of the following: [00:16] what if we add the xid to every connection/packet and hadnle/route this via some separate routing table ... [00:17] Are you talking about the private loopback or the ping problem above ? [00:17] well, the network per se ... of course the loopback can be solved that way too ... [00:18] You mean to tell people about using routing table selected by XID and then force vservers to tag every outgoing packet at the source (the XID could be the security context) [00:19] yes, sorry, I'm using xid like uid for context ;) [00:19] Hum. Not sure if the details but I like it. In fact, this could be a different thing from the security context. [00:20] yeah, sure, not necessarily bound to the context id ... [00:20] We could very well have a network ID as part of the set_ipv4root system call. [00:20] associated with a routing table ... [00:20] does vservers work with non ethernet devices ? [00:20] This could be a very useful feature. Currently, people have to set the IDs (IP marks) using iptable filter, but they lack the original context [00:21] could be even a netfilter extension and we could also tag/check for context marking ... [00:21] Yes jon. vserver really do not care about devices. The patch is really dealing with IP (ipv4 for now) only. You can setup vservers on loopback or dummy device if you want [00:22] jack: thanks [00:22] This network ID, I like it a lot. What I like is this is bigger than vserver. For example, someone could do the following [00:22] chbind --netid X execute this server [00:22] No --ip option, just a new --netid X option. [00:23] jup, should work ... [00:23] Now every packet sent by this server would be tagged and people could setup speed limit and quota for that service whatever the port it is using. [00:23] nevertheless I would like to have a virtual network interface for vserver ... [00:24] this way 'default' behaviour would be possible, and security would allow to process/check every packet ... [00:24] Ok, this netid stuff should really be pursued. Fun. back to the private loopback and virtual devices [00:25] for the loopback, I think it would be sufficient to add a context id to the sock structure ... [00:25] This network ID stuff does not help (I think) to solve the private loopback issue. The checks done by the kernel only look at IP, not device, not IDs [00:26] The sock structure already as the s_context in it. This is how netstat knows (or don't know) which socket to print in a vserver. [00:26] This was my idea to solve the private loopback. [00:26] ahh okay ... so this should be sufficient, right? [00:26] In the tests we do to find if a bind to 127.0.0.1:port is ok, the 127.0.0.1 would become a special case and the test would include the s_context field. [00:27] which function is this, do you know? [00:27] I think this would be enough and easy to solve have a real private loopback. Now, the virtual devices could serve other purposes [00:28] Let me check in the source. This is the stuff I changed back in ctx-16 allowing one vserver to have several IPs and do a bind ANY on them. Just a minute [00:29] Ok, got it, in net/ipv4 in function tcp_ipv4_addr_conflict [00:29] ahh yes ... [00:29] This function was added for the vserver project. Basically, the kernel does not care too much if many processes are bound to the same IP,same port. This [00:30] function checked this. [00:30] used in tcp_bind_conflict and udp_v4_get_port ... [00:31] Later, when we try to connect a socket, we use tcp_v4_lookup_listener. [00:31] The trick would be to match 127.0.0.1 and s_context and port when we match 127.0.0.1, not just 127.0.0.1 and port. [00:31] by the way, what would we need to allow ipv6 to work (for vserver) [00:31] This way we would end up with private loopback working normally [00:32] ipv6 would probably need the exact same hack we have now. [00:32] because we have a lot of people able and willing to test ipv6 ... [00:32] Same hack in route.h, in bind, connect etc... [00:33] I'm still hoping that we can find a 'virtualization' method which doesn't require the modifications at all ... [00:33] You talked about 1.2.0 lately. If we could have private loopback working and the limit stuff and the other stuff you think is reliable, we could attack ipv6 in 1.3 [00:34] I agree [00:34] FYI, I changed the dynamic context allocation in the latest release ... [00:34] I have push back the multiple IP bind any solution for a long time because I tought it would slow down things. It turns out to be not so bad [00:35] What's new ? [00:35] (sorry did not read the mailing list yesterday and today) [00:35] well, we had a possible deadlock .. when all dynamic IDs are used up .. [00:35] and a SMP race in dynamic allocation, holding a spinlock while calling kmalloc indirectly ... [00:36] btw, why did you picked such a high number (49000) ? [00:36] to get the dynamic stuff out of the static range already used ... [00:36] You needed that many static context ? [00:37] no, but folks tend to use 1000 or 10000 as base ... [00:37] Ok, not that I care. [00:37] and it is a #define anyway ... [00:37] Ok, back to private loopback. Do you agree about my private loopback solution ? [00:38] it sounds good, maybe some test implementation would be beneficial ... [00:38] Sure. Ok, I will look at it. Now back to chrootsafe() [00:38] I saw your trick and came with a very little solution, kind of weird to make chrootsafe() work in all case. Less general though. [00:38] okay, as far as I understood enrico, it cant work if we store only the last inode/path [00:39] actually enrico is doing all the chrootsafe() breaking stuff ;) [00:39] This is the idea. A process would have up to 3 bins to store the safe root. They are start NULLed [00:40] When you do chrootsafe(), it fills one saferoot (say saferoot0). When you do a second, it uses saferoot1 and so on. [00:40] When the kernel does it checks, instead of checking saferoot, it checks saferoot0,1 and 2. [00:40] This way, it never forget one saferoot. But you are limited to 3 imbeded chrootsafe() call. [00:40] guess that works, but not if you limit the number ... [00:41] What do you mean, limit the number [00:41] you would have to record a stack/list of barrier inodes ... [00:41] Yes this is true, this explains why I limit that to 2 ou 3 saferoots [00:42] The check done in the vfs accesses would still be very fast [00:42] personally I favour a different approach ... using namespaces instead of the chroot stuff ... [00:43] Another solution would be to have chrootsafe doing namespace stuff. I mean instead of a userland solution, chrootsafe would do everything. No need to let the process do remounts [00:43] hello, stackable chroot's will not protected against cross-vserver attacks when vservers are having different roots and sharing a filesystem [00:43] ahh, hello enrico ... [00:44] Why ? [00:45] since 2 vservers can have a distinct set of chrootsafe-bins. Now, first vserver transmits direcotry fd to second one, which can escape [00:46] Interesting. How does namespaces handle this ? [00:46] with namespace + remouting/pivot_root there is nothing before / [00:47] I would suggest a chroot replacement call, which 'crafts' the namespace for the task ... [00:47] What happens when the other vserver sends an fd of a directory from another namespace ? [00:48] jack: I never tried it, but either, it got's an IO error, or can walk in namespace of the first vserver only [00:48] make sens [00:49] maybe we could do something like the context for namespaces ... this way, you could enter 'named' namespaces ... [00:49] Bertl: I am not sure if such a syscall is really needed [00:49] usual CLONE_NEWNS + mount --rbind should work [00:50] the idea would be to 'associate' a namespace with a context or some namespace identifier .. this way you could 'join' such a namespace ... [00:52] btw, we should have a new capability to allow mount --bind. This is a general solution (mount --bind) to solve administrative task in a vserver and should not requires CAP_SYS_ADMIN [00:52] ahh okay, that is something I suggested some time ago, and we already have discussed an interface for that ... [00:53] so called 'per context capabilities' ... [00:54] this is a capability array, associated with the context, which allows to control the 'linux' capabilities in a finer grained way ... without adding capabilities to the default cap system ... [00:55] At some point we will have to connect with the LSM [00:55] that is true ... [00:58] LSM ? [00:58] Linux Security Modules ... [00:58] okay [01:01] ahh okay, before I forget, jack, does 0.28 support the kill_context stuff? [01:02] enrico, is this supported in 0.26 or some alpha version? [01:02] Bertl: adding ctx -> namespace relationship is good and imo necessarily because of security reasons. But it (should) work out of the box without an extra syscall. E.g. you can start a vserver with 'new-namespace { mount --rbind / ; chcontext } ... ', where the '{ ... }' part is a separate program [01:02] Bertl: no [01:03] okay, I just realized that this would immediately solve two of the to-do issues ... [01:03] Bertl: am I interpreting it right, that you have to know the ctx of a pid to use this syscall? Or is it be possbile to say 'ctx_kill(0, pid, 9)'? [01:04] No. Is this in 1.1.6 ? [01:04] yes, it's in 1.1.5 ;) [01:04] Bertl: would it break something to reomve the first line from [01:04] @enrico sec, looking at the code ... [01:04] + if (p->vx_id == id) [01:04] + retval = send_sig_info(vc_data.sig, &info, p); [01:04] + if (p->vx_id == id) [01:04] + retval = send_sig_info(vc_data.sig, &info, p); [01:05] oops, jittered too much. Should drink less coffee... [01:06] In 1.1.5, I have vc_ctx_kill as an empty function returning -ENOSYS. Am I missing something ? [01:06] ahh okay, you can do that with the admin context ... [01:06] @jack yes, there was the interface, the functionality is in 1.1.6 ... [01:07] Ok, I will implement this over the weekend. Will work also on private loopback [01:07] @enrico, using xid=1 and you can kill any pid ... [01:08] hmm sorry, I'm confused ... you can do that with xid=0 ... [01:10] Zoiah (Zoiah@81.17.52.139) got netsplit. [01:10] apw (~apw@212.104.150.41) got netsplit. [01:10] ccooke (~ccooke@80.1.164.238) got netsplit. [01:10] micah (micah@192.101.188.235) got netsplit. [01:10] mmh, I do not understand how... xid is not used in vc_ctx_kill() (1.1.6 patch) [01:11] ccooke (~ccooke@80.1.164.238) returned to #vserver. [01:11] micah (micah@192.101.188.235) returned to #vserver. [01:11] apw (~apw@212.104.150.41) returned to #vserver. [01:11] Zoiah (Zoiah@81.17.52.139) returned to #vserver. [01:11] if (!vx_check(0, VX_ADMIN)) [01:11] return -EPERM; [01:11] this allows only context id = 0 ... [01:11] if you specify a pid, the default path is used ... [01:12] this results in sending the signal to the task with that pid ... [01:12] no further security check ... [01:12] ah ok, but the '(p->vx_id == id)' checks are succeeding iff the given ctx is equal to the ctx of the process [01:12] this is only done if you specify pid<= 0 ... [01:13] no, default: has this check also [01:13] oops .. right ... [01:14] okay I change that to (!id || (p->vx_id == id)) [01:15] or would you prefer context 1 for that? [01:15] 0 is ok for me [01:16] @jack last time enrico and I talked about moving the context flags to a per context flagword ... which can be changed at runtime, what do you think about that? [01:18] Not sure I understand. Currently, if you set a vserver with a given flag and then you change the flag and reenter the vserver, the flag is change for all processes [01:19] yeah, we talked about 'moving' this interface to a separate syscall command, and extend it by the per context capabilities, this way removing the -1/-2/... hacks for the 'original' syscall ... [01:21] JonB (~jon@129.142.112.33) left irc: Quit: Client exiting [01:21] Zoiah (Zoiah@81.17.52.139) got netsplit. [01:21] apw (~apw@212.104.150.41) got netsplit. [01:21] ccooke (~ccooke@80.1.164.238) got netsplit. [01:21] micah (micah@192.101.188.235) got netsplit. [01:21] ccooke (~ccooke@80.1.164.238) returned to #vserver. [01:21] micah (micah@micha.hampshire.edu) joined #vserver. [01:21] Zoiah (Zoiah@matryoshka.zoiah.net) joined #vserver. [01:22] apw (~apw@212.104.150.41) returned to #vserver. [01:22] Bertl: you can check for '-1' instead of 0/1. This has a more clean semantic (no process can have ctx -1, but 0/1 are possbile) [01:23] okay ... [01:23] Yes -1, -2 -3 is very ugly. This was the cause of the security flaw in vserver 0.27. [01:23] Having a new entry in the switch is a good idea [01:23] -3 ? [01:23] no -3 does not exist. Just to mean the magic value are just hacks [01:24] okay, I draft the interface for that, and we talk about the semantics next time .. or via email, okay jack, enrico? [01:24] ok [01:25] http://vserver.13thfloor.at/Experimental/patch-killctx-fix.diff [01:25] this will be in 1.1.7 ... [01:29] @jack regarding the routing/source ip issues, what would be the consequences, if you specify --ip 0.0.0.0 for chbind? [01:41] It means you are out of it. No ipv4root restriction on this process. This is how it works now and only ctx0 can do that [01:42] It is an important feature. When you log to a root server using v_sshd, you may need to escape out of ipv4root to start some services [01:42] hmm, okay ... [01:43] also if you log using v_sshd and try to start another vserver, you must be allowed to select a totally different IP set [01:43] something completely different, I recently noticed some strange /dev/pts issues ... [01:44] first, devpts is 'adapted' but the devfs 'pts' is not ... but I'll add this soon ... I guess ;) [01:44] but that has nothing to do with the following: [01:45] sshd[2085]: Accepted password for ... from ... port ... ssh2 [01:45] sshd[2085]: error: openpty: No such file or directory [01:45] sshd[2087]: error: session_pty_req: session 0 alloc failed [01:46] and this is somewhat reproducible, but I'm currently not able to debug this ... everytime I do a debug trace and/or strace this issue completely disappears ... [01:46] I'm not even sure this _is_ a vserver issue ... [01:48] perhaps related with mc/w3m issues? [01:49] hmm, what do you mean? [01:49] I rad in maillist that w3m fails and mc sometime in vservers [01:50] hmm, do they allocate pseudo ttys ? [01:50] mc does it; dunno about w3m. pty's are just a guess, I never traced it [01:51] if this is reproducible somehow, I am willing to track this down ... [01:51] I read in the maillist archive about it... [01:51] okay .. will search for it ... [01:52] found nothing suspicious in the code, though ... but that doesn't say much ;) [01:52] has anybody had a look at the vskel stuff? [01:52] but it is probably vserver unrelated since I see similar faults on an embedded device with minimal /dev also [01:54] @jack,enrico recently somebody asked me, why there are two vserver tools, and why you do not work together on one version ... I had no answer to that question, maybe you could explain that? [01:59] Bertl: you asked me to create a second toolset ;) [01:59] is jack still there? [02:00] and "working together"... mmh ... vserver is too small and two cooks are ruining the pulp... [02:01] enrico, I'm totally indifferent to that, and I like your work, so don't get me wrong, I just passed this question on ... [02:04] enrico, IIRC, you do not want to maintain the newvserver script and some of the vunify stuff, right? [02:06] Bertl: you are right on newvserver. But vunify is needed, but requires a complete new implementation so that I will stay at it [02:06] and we are still missing a test suite for new releases ... [02:06] true... [02:07] well, the current situation is okay for me, as long as there _are_ new tools for new features ... so I'm not complaining at all ... [02:08] actually I'm happy that there are tools, and thank you all for doing this stuff ... [02:11] struct vcmd_ctx_caps_v0 { [02:11] uint32_t maxcaps; [02:11] uint32_t subcaps; [02:11] }; [02:11] would this be okay for capability settings? [02:12] for normal and per context ... [02:13] get and set command for that ... [02:13] do we need a mask for subcaps and/or maxcaps? [02:14] what are maxcaps and subcaps? [02:14] subcaps would be the per context capabilities ... [02:15] and maxcaps would be the upper bound for per context capabilities ... [02:17] hmm, should we propagate cap changes to the processes? [02:17] mmh, I do not understand why this is needed since capabilities can be removed only (but not gained) [02:19] okay, if we allow to take away/give capabilities on-the-fly from outside ... how would/should we handle that? [02:21] do we allow this? ctx is created with caps of parent ctx. After this initialization, caps can be removed only [02:23] yes, that is the current behaviour, but my impression was, that we would like to make this modifyable while the server is running ... maybe that isn't such a good idea at all ... at least not for the linux capabilities ... [02:26] do you have any application for this? [02:27] well, probably use for this is limited ... so let's scratch it ... [02:28] okay, what is the reason for the capability stuff in the new_s_context syscall command anyway? [02:30] probably, since there does not exist another way to set the ctx capabilities [02:37] okay, so we need cap_bset, but we don't want to change it at runtime, right? [02:42] you can change it at runtime, but its semantic would be 'remove', not 'set' [02:42] hmm, you could also 'add' or am I missing something? [02:43] parent process removes caps between 'create' and 'migrate' [02:43] yes, but as 'root' you can transfer capabilities, right? [02:44] current linux-caps would require CAP_PSET which has init only [02:45] that was the question, I could imagine that you 'add' the required capabilities on the fly from outside ... [02:46] I am back for few minutes: Why vunify need a new implementation ? [02:47] The problem with capability is that without the vserver project it is useless. Hum ? [02:47] Let me explain [02:48] jack: it is too specific for package management. I want something which is unifies filesystem trees [02:48] Capability are useful if you can tag them to files. This is not available now in linux. So while process may loose capability, setuid process are regaining them all [02:49] there is a hack in the kernel just for that. Everytime you execute a new program, you regain all capability. So vserver introduce the capability ceiling and setuid programs (root) [02:49] can't have more. [02:50] About vunify, it relies on packages and is distribution independant since it uses the distrib-info script to learn. Pick another name for the new tool. [02:50] jack: new vunify tool will have a legacy mode... [02:51] In fact the whole problem with capabilities is that it is useless anyway except for vservers. I mean, this is too broad. For example [02:51] (which calls the old tool) [02:51] Don't call it a legacy mode. Legacy means deprecated. Vunify uses package to perform unification and it unifies what needs and is fast. People may want to unify using other strategy (sam did that) [02:52] but this is less universal. vunify works with package so it let packages updates properly and do not confuse users. [02:52] Create another tool. [02:53] Or create new mode. Use the option --strategy for example (--strategy package, --strategy something), but not legacy. [02:54] and put a VUNIFYSTRATEGY= in /etc/vservers.conf or something like that, since vrpm and friends may want to redo unification after their work. [02:54] @jack what about working together on separate parts of 'the vserver tools?' ... [02:54] jack: this old configuration scheme went away in alpha branch [02:55] While I was away (not too much responding to email), I don't know what happened so can't juge enrico. All I see is that strange decision are being taken and this kind of irritate me. [02:56] I have talked about upgrade path and people did not seem to care. I am supporting quite a few people with hundreds of vserver installation. I do care about compatibility issue. [02:56] What old configuration scheme ? [02:56] okay, maybe I should explain how this happened, as it is partly my fault ... [02:56] the /etc/vservers/.conf based one [02:57] please take a step back from the details ... and look at the picture ... [02:57] new one has /etc/vservers// directory where the parameters are stored in snigle files [02:57] the shell-like configuration is not powerful enough to set certain parameters [02:58] (and makes e.g. C implementations complicated) [02:58] Having one directory per vserver is probably a good idea since other configuration may appear in the future. [02:59] Yes but make shell script potentially complicate. But this is workable. For example we may have a tool call vprintconf which print a set of var= var= values and we can eval that in bash [02:59] Or we can have the reverse where the a script is run and output a more easily parsed file for C. [03:00] when you can read XML: http://savannah.nongnu.org/cgi-bin/viewcvs/util-vserver/util-vserver/doc/configuration.xml?rev=1.2&content-type=text/vnd.viewcvs-markup is the begin of some documentation [03:01] @jack do you miss the smooth migration path, if so, why? and how could we ease that? [03:01] XML is nice and for some reason never kicked off as a configuration format. Not sure why. I guess it turns ugly fast. People seems to like to just # comment away things [03:02] Ok wait wait wait and wait again [03:02] ahh, got some attention there? ;) [03:03] it is not a configuration file, it's the documentation of the configuration ;) [03:03] When I agree to let you drive the project, there were very little things that cause grief. We had missunderstanding on many little things and I could not figure why this was causing such a problem. [03:04] I said, maybe it is me, maybe it is not me. So I decided to let you go and let things happen. I was not confortable with the way things were happening, but I again decide to let it go. [03:05] morning [03:05] I was not confortable with that, but I found my confort zone. Basically, when I decided to continue the vserver package, I found a way to support the current user and continue to contribute. [03:06] the old/legacy configuration will be still supported [03:09] @jack so what is your point? are you not 'satisfied' with the way vserver development evolves? [03:09] I don't think so and this is part of the little problems. Basically, when you said things like newvserver is gone or whatever, it means you do not care. People are using that you know. [03:10] bertl. I am now satisfied with the way the kernel evolves and the packaging you do and the support you give on the mailing list. Seems like you are 24 hours a day on it. [03:10] ahh you got me wrong there ... I never 'eliminated' or 'removed' anything ... and we never broke anything on purpose ... [03:11] Not your bertl. I have let you go on the kernel stuff, the site and so on and I am happy now [03:11] @jack okay, so you are not satisifed with the tools then, right? [03:11] The vserver project is both a small and big project. On the big side of it, it includes administration practice and so on [03:11] (yes the tool) [03:12] well, that is why I suggested to split the tools in at least two parts ... [03:12] The same way debian and redhat may have different way to approach solution and different goals, it seems vserver and util-vserver do have different goals. [03:13] Ok here is a proposition [03:13] and work together on that, because both approaches have advantages over the other ... [03:13] for example, I would not be happy with a one-value-per-file approach, enrico favours (he knows that), but I can see some advantages in doing so ... [03:13] Give me some time. During that time, both vserver and util-vserver will evolve following kind of each other. At some point, we will see how things should be done. [03:14] okay, sounds reasonable, is this okay for you too, enrico? [03:14] So to conclude (I will leave in a few seconds) [03:15] not a problem with me [03:15] Things are rolling again for me with this project. Some false starts and disagreement at the begining. [03:16] we will talk about that, and find a beneficial solution for everything ... [03:16] I will continue vserver stuff and kernel stuff for a while and we will reconsider. One dark/bright side of open source is the fork. The bright side is when the unfork is done :-) [03:17] okay, you will work on what? in the next time (kernel related?) [03:17] just to make sure, we are not working in parallel on the same feature ;) [03:17] Ok, again I have kind of found my confort zone in the new setup and I will cruise this way for a while [03:17] kernel: private loopback first [03:18] okay, if possible, have a look at the ipv6 stuff, this _is_ something requested often ... [03:18] vserver: security feature, trustable root vserver, general administration, monitoring [03:18] I will work on the virtual network interface, and see how far I can get ... [03:19] Anyway, have a good weekend. I am confident we will make a success of this whole thing. [03:19] some info regarding the kernel interface: we will move the rlimit stuff into a separate interface ... [03:19] BTW. Do you know the RMLL ? [03:19] No problem with rlimit [03:20] RMLL means? [03:20] It is a french (france) event in Bordeaux. It is the libre software meeting. This is the fifth year. This is completly open [03:21] Open means free like free beer. [03:21] ahh good, no I don't know it ... [03:21] Basically, they are inviting speakers and various people (generally from europe) atttend. [03:21] I have been there for the last four event in july. [03:22] I expect to be invited again this year. I suggest you register for a talk on vserver this year. Check rmll.org to see when you can register. We can meet there maybe. [03:22] sounds interesting ... I'll see if it's possible ... [03:23] no problem with rlimit means: Yes go for it. [03:23] RMLL can sponsor your trip there btw. [03:23] hmm rmll.org gives funny result ... [03:23] maja|ipv6 (maharaja@ipax.tk) left irc: Read error: Connection reset by peer [03:24] Anyway, I have to leave now. The netid things is interesting to say the least. Maybe I will find a way to plug that while doing the private loopback stuff. [03:24] hehe, red mountain little league! [03:24] try lsm.abul.org [03:25] okay, have a nice weekend ... [03:25] Anyway, we will talk about the rmll later. I think they open for speaker in January [03:25] bye [03:25] jack (~jack@route3.unigiciel.com) left irc: Quit: using sirc version 2.211+KSIRC/1.2.4 [03:26] okay, enrico, how do we proceed regarding the cap_bset for vserver? [03:28] new_cap = ((cap & CAPCTX_PCAP) ? ~0 : cap) & mask [03:29] hmm, please elaborate ... [03:29] mask is passed in the syscall command ... [03:29] cap are the caller's capabilities, mask the syscall parameter, and new_cap the new capability [03:30] second 'cap' should be the ctx-cap [03:30] ctx_cap = ((cap & CAPCTX_PCAP) ? ~0 : ctx_cap) & mask [03:30] ahh okay ... so you 'allow' changes if a special per context CAP_PCAP is set? [03:30] yes [03:31] so it would be new_cap = ((ctx_cap & CAPCTX_PCAP) ? ~0 : cap) & mask , right? [03:32] yes [03:32] okay, and how (if at all?) do we propagate this? [03:32] where to propagate? [03:33] okay, I have a cap_bset per context ... in the current implementation [03:33] this is set by the 'initial' new_s_context ... [03:33] and used for cap change limitations ... [03:33] yes, as new_cap = ctx_cap & ~CAPCTX_CAP [03:33] new_permitted = cap_intersect(bprm->cap_permitted, current->cap_bset); [03:35] okay, maybe we should look at some use-cases ... [03:35] usually we have the --secure capset right? [03:36] people often add CAP_NET_RAW and CAP_RESOURCE *shudder* and CAP_SYS_ADMIN .... [03:36] these caps will be removed between create and migrate [03:36] (or better: create and activate) [03:37] well, yes, they actually are used everytime the capability set is changed ... [03:38] let us ignore the finer grained per context capability set for now ... [03:38] somebody adds CAP_NET_RAW for vserver xyz ... [03:39] no, he can not add it [03:39] well, he could add it to cap_bset ... [03:39] cap_bset contains caps of parent [03:40] no, cap_bset is per context ... [03:40] he can remove ~(xxx & CAP_NET_RAW) from it only [03:40] yes, the caps of the parent context [03:41] intersected with process caps [03:42] * The formula used for evolving capabilities is: [03:42] * [03:42] * pI' = pI [03:42] * (***) pP' = (fP & X) | (fI & pI) [03:42] * pE' = pP' & fE [NB. fE is 0 or ~0] [03:42] * [03:42] * I=Inheritable, P=Permitted, E=Effective // p=process, f=file [03:42] * ' indicates post-exec(), and X is the global 'cap_bset'. [03:42]