On Sun, 2 Sep 2001, Andreas Amann wrote: Once again: hello everybody! after doing some experiments this morning i think i've found the major problem with compartment's --cap option (although: compartment has nothing to to with that!).
[...] So, for example, the command 'compartment --chroot /some/dir --cap none --verbose /daemon/with_uid0/port_below_1024' should fail miserably because the daemon won't be able to bind to it's port. But exactly this works and i am wondering why (compartment tells me that it successfully set caps to 0x0). [...] The problem here is the following: I've made my tests with the proftpd and bind9 that have to start as root in order to bind to their well known ports below 1024. Compartment in fact set the three capsets to zero, but i did not recognize that these programs also make use of the capset() syscall to risen their privileges themselves. In fact, this seems to be totally legal because the value in /proc/sys/kernel/cap_bound was set to -256 and seems to be the systemwide default-setting any process becomes after startup. This value includes the CAP_NET_BIND_SERVICE capability. So they were able to start up cleanly. Another funny thing is: after switching over to user nobody, group nogroup proftpd set its capabilities to zero (to be seen via /proc/<PID>/status). After setting cap_bound to a lower value without the CAP_NET_BIND_SERVICE cap, those services failed as expected.
- Is it true that --cap only works with CAP_INIT_EFF_SET and CAP_INIT_INH_SET set to -1 in <linux/capability.h> in order to get the CAP_SETPCAP privilege? These defines seem not to manipulate the capsets of the init process as i first thought but they set the systemwide default for /proc/.../cap_bound. The init process seems to have always full privileges, but i did not check this so far. Setting these defines to -1 would in fact be a quite bad idea.
To make things still a bit more complicated you can't set cap_bound to a higher value without the CAP_SETPCAP privilege (only init seems to have it by default but can't make use of it), although it is told that you are able to modify it via /dev/mem because of a bug (see http://home.netcom.com/~spoon/lcap/). Although a good idea, capabilities don't seem to be quite useful at the moment (programmers may think different!). But maybe someone is able to enlighten me in this point.... Nevertheless, sorry for wasting your time. Next time i will think about it a second time before making a posting here.... with kind regards Andreas Amann <mailto:andreas.amann@epost.de>