newly started process no matter whether it will run as root or not. 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). I am using SuSE 7.2 with a (stock) Kernel 2.4.9 (but it also happens with a SuSE 2.2.19). /proc/sys/kernel/cap_bound says -257, say everything except CAP_SETPCAP.
I've been playing around with it last weekend, too, and I can verify the problem. Something is wrong here, and I've decided to dig up some kernel code to find out.
So thinking about that and the stuff i've read in the 'capfaq' from http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.2/capfaq-... i have the following questions:
- Is it true that --cap only works with CAP_INIT_EFF_SET and CAP_INIT_INH_SET set to -1 in
in order to get the CAP_SETPCAP privilege?
Inheritable means that the children will have these capabilities.
- If so, doesn't it give even more problems when granting the CAP_SETPCAP right to init? I think this would mean that every process started by init will have it. - If not, do i totally missunderstand something and everything is working well except me?
Not sure yet. :-/ If anybody else is playing around with it as well, please step up!
Thanks in advance to everyone who will be so friendly to help me with that!
With kind regards
Andreas Amann mailto:andreas.amann@epost.de
Thanks,
Roman.
--
- -
| Roman Drahtmüller