Please apply this patch to baselayout. It is necessary for POSIX 1003.1e capability-enabled systems (without it, the whole system will break).
Created attachment 2708 [details, diff] POSIX 1003.1e capabilities patch for sysvinit
Url with more info please.
The URL on the bug report (http://original.killa.net/infosec/caps/) contains most of the info. The Linux Capabilites FAQ can be found on http://ftp.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4/capfaq-0.2.txt. The POSIX 1003.1e draft can be downloaded in PDF format from http://acl.bestbits.at/posix/posix_1003.1e-990310.pdf.
Did a bit of reading. Seems that it is disabled by default for a reason, as with it enabled, any process/user can inherit it, which could be a bad thing. As it can be enabled by editing the kernel source, I think it will be best to let the user choose if he wants it or not. Comments ?
Yes, everybody could inherit a capability. But as long as no capability is in the permitted set, nothing can be inherited. The default setting of /proc/sys/kernel/cap-bound ensures that root processes get all capabilites and user processes get no capabilites. So it won't do any harm on capability-disabled systems. PS: I'm away from home for the next three weeks.
Any updates on this? As far as I can tell, this has to do with the "Default Linux Capabilities" as found in 2.6 kernels. My system(s) run fine with this enabled, even though I don't know what it does (and sometimes not what I'm doing either) There's no mention of bug 5818 or capabilities in the Changelog for baselayout-1.8.6.10-r1.
I found this thread just by luck, but Gentoo claims it is POSIX compliant. Therefore, head(1), tail(1) and other utilies do change their behaviour. See the thread at http://lists.gnu.org/archive/html/bug-coreutils/2003-09/msg00087.html However, if Gentoo still claims it is a POSIX system, the patch probably should be considered (although I can't comment on it).
Hrm, where exactly do we claim we're POSIX compliant? If we're really claiming that, I have various other changes that're needed...
ignoring comment #7 which is clearly wrong, i cleaned up the patch and added to 2.86-r3
This patch doesn't build on SPARC using gcc-3.3.x and 2.3.3.20040420-r2 (current default profile versions for ~sparc keyword); sparc-unknown-linux-gnu-gcc -c -mcpu=ultrasparc3 -mvis -O2 -pipe -Wa,-Av8plusa -Wall -D_GNU_SOURCE -DINIT_MAIN utmp.c -o init_utmp.o sparc-unknown-linux-gnu-gcc -o init init.o init_utmp.o init.o: In function `capget': init.c:(.text+0x134): undefined reference to `errno' init.c:(.text+0x13c): undefined reference to `errno' init.o: In function `capset': init.c:(.text+0x194): undefined reference to `errno' init.c:(.text+0x19c): undefined reference to `errno' collect2: ld returned 1 exit status make: *** [init] Error 1 make: Leaving directory `/var/tmp/portage/sysvinit-2.86-r3/work/sysvinit-2.86/src'
i'd say your headers suck because your linux/unistd.h is wrongly doing 'extern int errno' instead of '#include <errno.h>' this has been fixed in our 2.6.11 headers
We're stuck on 2.4 headers until 2006.0 at the earliest for ~sparc and not sure when stable will come (due to stability issues in the 2.6 kernel). I'll take a look at the 2.4 headers unless that's what you're explicitly commenting on.
i wasnt saying you have to upgrade to 2.6 headers, i was suggesting you fix your broken headers ;) i was about to fix 2.4.26-r1 (because i use that on a bunch of my arches)
The revision bump of linux-headers-2.4.26-r1 did the trick. Resolving again
