We currently migrate to MediaWiki from our old installation, but not all content has been migrated yet. Take a look at the Wiki Team page for instructions how to help or browse through our new wiki at wiki.linux-vserver.org to find the information already migrated.

Patches are at [grepmaster linux-vserver patch repository].

Procedure 1 (for the more paranoid)

Procedure 2 (for the less paranoid)

As far as the grsecurity additional chroot restrictions go, I have the following turned off and all the rest turned on:

The first is necessary for gentoo emerge as well as running daemons within chroot (djbdns, or whatever). The second is necessary for upgrading packages with suid files in them (common task). The third does not seem necessary for Debian but breaks Gentoo emerge when turned on.

There's currently an issue on using GR Security 1.9.x ACLs since once the ACL is applied the CAP_SYS_ADMIN is dropped and it can not be recovered for editing or disabling the ACL.

# gradm -E

# gradm -a

Password:

Could not open /proc/sys/kernel/grsecurity/acl

open: Permission denied

Kernel log shows this:

Mar 30 09:31:47 alus2 kernel: grsec: From 192.168.1.2: use of CAP_SYS_ADMIN denied for (gradm:1374) UID(0) EUID(0), parent (bash:706) UID(0) EUID(0)

(why it's denied? It never happens in grsec+gradm only)

The consecuence is that the first ACL can not be undone, it's permanent. Deep testing is recomended before using ACLs on production servers with GR Security + vserver patches.

[Thank you for explainig this issue - Maybe this is only an issue with grsecurity 1.9.x, because I use grsecurity 2.0/vserver 1.3.9 and after enabling the ACLs with "gradm -E" I can still get the admin role with "gradm -a admin" and then reload new ACLs with "gradm -R" - tested in context 0.]

send requests / compliments / flames to

jeffrey+vserver AT firehead DOT org