Hi > 3 possibilities: > 1. disable ALL chroot restrictions when vserver kernel is enabled > 2. disable the 4 restrictions and leave the choice for the rest of the > chroot restrictions > 3. SCREW IT, I'm a grown boy, i decide what i want, this is a free country > (wether or not you live in one ;)) > > anyway, I personally would disable all chroot restrictions, since security > on the guests is primarily enforced by vserver code itself. The second > option has more options for the user (do you want that?) > Based on a position of ignorance I have been running your merged kernel sources for the last few years with something like the following options: [*] Chroot jail restrictions [ ] Deny mounts [ ] Deny double-chroots [*] Deny pivot_root in chroot [*] Enforce chdir("/") on all chroots [ ] Deny (f)chmod +s [*] Deny fchdir out of chroot [*] Deny mknod [*] Deny shmat() out of chroot [*] Deny access to abstract AF_UNIX sockets out of chroot [*] Protect outside processes [ ] Restrict priority changes [*] Deny sysctl writes [ ] Capability restrictions So, unless you tell me that some of these options are already irrelevant because of the vserver patches then it seems like it's useful to leave them available? Disabling the 4 relevant options when using vserver seems extremely sensible though (option 2) and would appear to be a fairly straightforward change and the minimum we should do? I guess I would like to hear more reasons why option 3) is actually useful? Seems on the surface to cause few problems and only reduce security/choice? However, I concede huge ignorance on the effects of these options... Thanks for continuing to maintain this! Ed W