[<prev] [next>] [thread-next>] [day] [month] [year] [list]
Message-ID: <52DE7557.3000500@gmail.com>
Date: Tue, 21 Jan 2014 13:25:43 +0000
From: Aaron Jones <aaronmdjones@...il.com>
To: linux-kernel@...r.kernel.org
Subject: File capabilities are not 'working' and I have no idea why
Hello.
I recently upgraded from 3.10.7 on a long-running box to 3.12.8 on a
new box. I have been using file capabilities for a long time, so that
processes do not need to start as root and drop unnecessary privileges
later.
For example, there is no reason for my bind9 nameservers to start as
root, except to bind() port 53 and 953. What I did in this case was to
chown it to root:named and chmod it to 0750 and assign
CAP_NET_BIND_SERVICE to it, it then starts as named and works fine.
I haven't had any issues with this for easily a year, until now. No
matter what I do on this new machine, I cannot get file capabilities
to 'work'. They are set fine, they are read back fine, but they don't
do anything. I have attached my kernel boot log, its configuration and
a test program (build with -std=c99 -lcap-ng).
My problem follows:
# strace -f setcap cap_net_bind_service+eip /usr/local/bin/caps 2>&1 \
| grep xattr
setxattr("/usr/local/bin/caps", "security.capability", \
"\x01\x00\x00\x02\x00\x04\x00\x00\x00\x04\x00\x00\x00\x00\x00\x00 \
\x00\x00\x00\x00", 20, 0) = 0
# getcap /usr/local/bin/caps
/usr/local/bin/caps = cap_net_bind_service+eip
$ /usr/local/bin/caps
Effective capabilities: (none)
Permitted capabilities: (none)
And the CapEff and CapPrm fields in /proc/pid/status are all zero!
There is nothing in the kernel log, before or after the execution,
that is relevant to capabilities. Some additional information:
# cat /proc/version
Linux version 3.12.8 (root@...adel) (gcc version 4.7.3 (Gentoo \
Hardened 4.7.3-r1 p1.4, pie-0.5.5)) #1 SMP Tue Jan 21 12:26:18 \
UTC 2014
# cat /proc/sys/kernel/tainted
0
# mount | grep ' / '
/dev/sda2 on / type ext4 (rw,nosuid,relatime,data=ordered)
# equery belongs $(which setcap)
sys-libs/libcap-2.22 (/sbin/setcap)
Extended attributes do indeed work:
# echo testing > /usr/local/bin/test
# chown root:root /usr/local/bin/test
# chmod 0600 /usr/local/bin/test
# strace -f setfacl -m u:aaron:r /usr/local/bin/test \
2>&1 | grep xattr
getxattr("/usr/local/bin/test", "system.posix_acl_access", \
0x7fffffffce00, 132) = -1 ENODATA (No data available)
setxattr("/usr/local/bin/test", "system.posix_acl_access", \
"\x02\x00\x00\x00\x01\x00\x06\x00\xff\xff\xff\xff\x02\x00\x04\x00 \
\xe8\x03\x00\x00\x04\x00\x00\x00\xff\xff\xff\xff\x10\x00\x04\x00 \
\xff\xff\xff\xff \x00\x00\x00 \xff\xff\xff\xff", 44, 0) = 0
$ cat /usr/local/bin/test
testing
Does anyone have an insight here? I'm about ready to pull my hair out
over this. I've been going at this for 3 days now...
I am subscribed, but please CC me in replies so that they come to my
attention immediately.
Thanks in advance,
Aaron Jones.
View attachment "bootlog.txt" of type "text/plain" (34108 bytes)
View attachment "kernel.config" of type "text/plain" (44988 bytes)
View attachment "caps.c" of type "text/x-csrc" (677 bytes)
Powered by blists - more mailing lists