Latest working kernel version: 2.6.25 Earliest failing kernel version: 2.6.26-rc1 Distribution: Kubuntu Hardy Hardware Environment: AMD Software Environment: Problem Description: On a default Kubuntu Hardy install, I fetched the git tree from Linus; compiled and installed the kernel. This persists even with 2.6.26-rc2+ (commit f26a3988917913b3d11b2bd741601a2c64ab9204) If this isn't known, I'll bisect and report the bad commit Steps to reproduce: 'sudo dhclient eth2' returns drop_privileges: could not keep capabilities: Invalid argument eth2 is an e1000e card.
Created attachment 16195 [details] Config
Reply-To: akpm@linux-foundation.org (switched to email. Please respond via emailed reply-to-all, not via the bugzilla web interface). On Mon, 19 May 2008 06:25:00 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote: > http://bugzilla.kernel.org/show_bug.cgi?id=10748 > > Summary: dhclient fails to run; capabilities error > Product: Networking > Version: 2.5 > KernelVersion: 2.6.26-rc2 > Platform: All > OS/Version: Linux > Tree: Mainline > Status: NEW > Severity: normal > Priority: P1 > Component: IPV4 > AssignedTo: shemminger@linux-foundation.org > ReportedBy: shahamit@gmail.com > > > Latest working kernel version: 2.6.25 > Earliest failing kernel version: 2.6.26-rc1 > Distribution: Kubuntu Hardy > Hardware Environment: AMD > Software Environment: > Problem Description: On a default Kubuntu Hardy install, I fetched the git > tree > from Linus; compiled and installed the kernel. This persists even with > 2.6.26-rc2+ (commit f26a3988917913b3d11b2bd741601a2c64ab9204) > > If this isn't known, I'll bisect and report the bad commit > > Steps to reproduce: 'sudo dhclient eth2' returns > > drop_privileges: could not keep capabilities: Invalid argument > > eth2 is an e1000e card. > > whoa, weird. Could you please run `sudo strace -f dhclient eth2' and send us the last page or so of output?
Quoting Andrew Morton (akpm@linux-foundation.org): > (switched to email. Please respond via emailed reply-to-all, not via the > bugzilla web interface). > > On Mon, 19 May 2008 06:25:00 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > > > http://bugzilla.kernel.org/show_bug.cgi?id=10748 > > > > Summary: dhclient fails to run; capabilities error > > Product: Networking > > Version: 2.5 > > KernelVersion: 2.6.26-rc2 > > Platform: All > > OS/Version: Linux > > Tree: Mainline > > Status: NEW > > Severity: normal > > Priority: P1 > > Component: IPV4 > > AssignedTo: shemminger@linux-foundation.org > > ReportedBy: shahamit@gmail.com > > > > > > Latest working kernel version: 2.6.25 > > Earliest failing kernel version: 2.6.26-rc1 > > Distribution: Kubuntu Hardy > > Hardware Environment: AMD > > Software Environment: > > Problem Description: On a default Kubuntu Hardy install, I fetched the git > tree > > from Linus; compiled and installed the kernel. This persists even with > > 2.6.26-rc2+ (commit f26a3988917913b3d11b2bd741601a2c64ab9204) > > > > If this isn't known, I'll bisect and report the bad commit > > > > Steps to reproduce: 'sudo dhclient eth2' returns > > > > drop_privileges: could not keep capabilities: Invalid argument > > > > eth2 is an e1000e card. > > > > > > whoa, weird. Could you please run `sudo strace -f dhclient eth2' and send us > the last page or so of output? Also, please send your .config, or at least the result of grep SECURITY .config thanks, -serge
On Tue, 2008-05-20 at 08:49 -0500, Serge E. Hallyn wrote: > Quoting Andrew Morton (akpm@linux-foundation.org): > > (switched to email. Please respond via emailed reply-to-all, not via the > > bugzilla web interface). > > > > On Mon, 19 May 2008 06:25:00 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=10748 > > > > > > Summary: dhclient fails to run; capabilities error > > > Product: Networking > > > Version: 2.5 > > > KernelVersion: 2.6.26-rc2 > > > Platform: All > > > OS/Version: Linux > > > Tree: Mainline > > > Status: NEW > > > Severity: normal > > > Priority: P1 > > > Component: IPV4 > > > AssignedTo: shemminger@linux-foundation.org > > > ReportedBy: shahamit@gmail.com > > > > > > > > > Latest working kernel version: 2.6.25 > > > Earliest failing kernel version: 2.6.26-rc1 > > > Distribution: Kubuntu Hardy > > > Hardware Environment: AMD > > > Software Environment: > > > Problem Description: On a default Kubuntu Hardy install, I fetched the > git tree > > > from Linus; compiled and installed the kernel. This persists even with > > > 2.6.26-rc2+ (commit f26a3988917913b3d11b2bd741601a2c64ab9204) > > > > > > If this isn't known, I'll bisect and report the bad commit > > > > > > Steps to reproduce: 'sudo dhclient eth2' returns > > > > > > drop_privileges: could not keep capabilities: Invalid argument > > > > > > eth2 is an e1000e card. > > > > > > > > > > whoa, weird. Could you please run `sudo strace -f dhclient eth2' and send > us > > the last page or so of output? > > Also, please send your .config, or at least the result of > grep SECURITY .config His .config was attached to the bugzilla. CONFIG_SECURITY=y CONFIG_SECURITY_NETWORK=y # CONFIG_SECURITY_NETWORK_XFRM is not set # CONFIG_SECURITY_CAPABILITIES is not set CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 # CONFIG_SECURITY_SELINUX is not set Which means that he is using the dummy security module. And it appears that a prior commit moved KEEPCAPS handling from core prctl() to cap_task_prctl(), but didn't replicate it in the dummy_task_prctl(). The dummy module really needs to die.
On Mon, May 19, 2008 at 11:58 PM, Andrew Morton <akpm@linux-foundation.org> wrote: > whoa, weird. Could you please run `sudo strace -f dhclient eth2' and send us > the last page or so of output? > Sorry, I should've done that earlier. 9311 open("/var/lib/dhcp3/dhclient.leases", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 4 9311 chown("/var/lib/dhcp3/dhclient.leases", 100, 4294967295) = 0 9311 fstat(4, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 9311 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc511e8f000 9311 write(4, "lease {\n interface \"eth0\";\n fi"..., 531) = 531 9311 open("/var/run/dhclient.pid", O_WRONLY|O_CREAT|O_TRUNC, 0644) = 5 9311 fcntl(5, F_GETFL) = 0x8001 (flags O_WRONLY|O_LARGEFILE) 9311 fstat(5, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0 9311 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc511e8e000 9311 lseek(5, 0, SEEK_CUR) = 0 9311 open("/etc/passwd", O_RDONLY|0x80000 /* O_??? */) = 6 9311 lseek(6, 0, SEEK_CUR) = 0 9311 fstat(6, {st_mode=S_IFREG|0644, st_size=1558, ...}) = 0 9311 mmap(NULL, 1558, PROT_READ, MAP_SHARED, 6, 0) = 0x7fc511e8d000 9311 lseek(6, 1558, SEEK_SET) = 1558 9311 munmap(0x7fc511e8d000, 1558) = 0 9311 close(6) = 0 9311 socket(PF_FILE, SOCK_STREAM, 0) = 6 9311 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 9311 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) 9311 close(6) = 0 9311 socket(PF_FILE, SOCK_STREAM, 0) = 6 9311 fcntl(6, F_SETFL, O_RDWR|O_NONBLOCK) = 0 9311 connect(6, {sa_family=AF_FILE, path="/var/run/nscd/socket"}, 110) = -1 ENOENT (No such file or directory) 9311 close(6) = 0 9311 open("/etc/group", O_RDONLY|0x80000 /* O_??? */) = 6 9311 lseek(6, 0, SEEK_CUR) = 0 9311 fstat(6, {st_mode=S_IFREG|0644, st_size=923, ...}) = 0 9311 mmap(NULL, 923, PROT_READ, MAP_SHARED, 6, 0) = 0x7fc511e8d000 9311 lseek(6, 923, SEEK_SET) = 923 9311 munmap(0x7fc511e8d000, 923) = 0 9311 close(6) = 0 9311 prctl(0x8, 0x1, 0, 0, 0) = -1 EINVAL (Invalid argument) 9311 dup(2) = 6 9311 fcntl(6, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE) 9311 fstat(6, {st_mode=S_IFCHR|0600, st_rdev=makedev(136, 2), ...}) = 0 9311 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fc511e8d000 9311 lseek(6, 0, SEEK_CUR) = -1 ESPIPE (Illegal seek) 9311 write(6, "drop_privileges: could not keep "..., 63) = 63 9311 close(6) = 0 9311 munmap(0x7fc511e8d000, 4096) = 0 9311 exit_group(-1) = ?
On Tue, 2008-05-20 at 09:38 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 08:49 -0500, Serge E. Hallyn wrote: > > Quoting Andrew Morton (akpm@linux-foundation.org): > > > (switched to email. Please respond via emailed reply-to-all, not via the > > > bugzilla web interface). > > > > > > On Mon, 19 May 2008 06:25:00 -0700 (PDT) bugme-daemon@bugzilla.kernel.org > wrote: > > > > > > > http://bugzilla.kernel.org/show_bug.cgi?id=10748 > > > > > > > > Summary: dhclient fails to run; capabilities error > > > > Product: Networking > > > > Version: 2.5 > > > > KernelVersion: 2.6.26-rc2 > > > > Platform: All > > > > OS/Version: Linux > > > > Tree: Mainline > > > > Status: NEW > > > > Severity: normal > > > > Priority: P1 > > > > Component: IPV4 > > > > AssignedTo: shemminger@linux-foundation.org > > > > ReportedBy: shahamit@gmail.com > > > > > > > > > > > > Latest working kernel version: 2.6.25 > > > > Earliest failing kernel version: 2.6.26-rc1 > > > > Distribution: Kubuntu Hardy > > > > Hardware Environment: AMD > > > > Software Environment: > > > > Problem Description: On a default Kubuntu Hardy install, I fetched the > git tree > > > > from Linus; compiled and installed the kernel. This persists even with > > > > 2.6.26-rc2+ (commit f26a3988917913b3d11b2bd741601a2c64ab9204) > > > > > > > > If this isn't known, I'll bisect and report the bad commit > > > > > > > > Steps to reproduce: 'sudo dhclient eth2' returns > > > > > > > > drop_privileges: could not keep capabilities: Invalid argument > > > > > > > > eth2 is an e1000e card. > > > > > > > > > > > > > > whoa, weird. Could you please run `sudo strace -f dhclient eth2' and > send us > > > the last page or so of output? > > > > Also, please send your .config, or at least the result of > > grep SECURITY .config > > His .config was attached to the bugzilla. > CONFIG_SECURITY=y > CONFIG_SECURITY_NETWORK=y > # CONFIG_SECURITY_NETWORK_XFRM is not set > # CONFIG_SECURITY_CAPABILITIES is not set > CONFIG_SECURITY_DEFAULT_MMAP_MIN_ADDR=0 > # CONFIG_SECURITY_SELINUX is not set > > Which means that he is using the dummy security module. > And it appears that a prior commit moved KEEPCAPS handling from > core prctl() to cap_task_prctl(), but didn't replicate it in > the dummy_task_prctl(). > > The dummy module really needs to die. Question for the bug reporter: did you really mean to build a kernel without capabilities support? Surprise! They don't really work when disabled.
On Tue, May 20, 2008 at 7:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > On Tue, 2008-05-20 at 09:38 -0400, Stephen Smalley wrote: >> Which means that he is using the dummy security module. >> And it appears that a prior commit moved KEEPCAPS handling from >> core prctl() to cap_task_prctl(), but didn't replicate it in >> the dummy_task_prctl(). >> >> The dummy module really needs to die. > > Question for the bug reporter: did you really mean to build a kernel > without capabilities support? Surprise! They don't really work when > disabled. No; I was just trying out some random configs. This config worked till .25 properly though.
On Tue, 2008-05-20 at 19:37 +0530, Amit Shah wrote: > On Tue, May 20, 2008 at 7:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > On Tue, 2008-05-20 at 09:38 -0400, Stephen Smalley wrote: > >> Which means that he is using the dummy security module. > >> And it appears that a prior commit moved KEEPCAPS handling from > >> core prctl() to cap_task_prctl(), but didn't replicate it in > >> the dummy_task_prctl(). > >> > >> The dummy module really needs to die. > > > > Question for the bug reporter: did you really mean to build a kernel > > without capabilities support? Surprise! They don't really work when > > disabled. > > No; I was just trying out some random configs. This config worked till > .25 properly though. The dummy module is generally in the untenable position of having to lie to userspace or break the existing capability-related system call interface. It should just go away, and make capability the default module (w/ stubs for the rest of the LSM hooks as with dummy). Then CONFIG_SECURITY=n will yield the same result as CONFIG_SECURITY=y w/o any further options.
On Tue, 2008-05-20 at 10:45 -0400, Stephen Smalley wrote: > On Tue, 2008-05-20 at 19:37 +0530, Amit Shah wrote: > > On Tue, May 20, 2008 at 7:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote: > > > > > > On Tue, 2008-05-20 at 09:38 -0400, Stephen Smalley wrote: > > >> Which means that he is using the dummy security module. > > >> And it appears that a prior commit moved KEEPCAPS handling from > > >> core prctl() to cap_task_prctl(), but didn't replicate it in > > >> the dummy_task_prctl(). > > >> > > >> The dummy module really needs to die. > > > > > > Question for the bug reporter: did you really mean to build a kernel > > > without capabilities support? Surprise! They don't really work when > > > disabled. > > > > No; I was just trying out some random configs. This config worked till > > .25 properly though. > > The dummy module is generally in the untenable position of having to lie > to userspace or break the existing capability-related system call > interface. It should just go away, and make capability the default > module (w/ stubs for the rest of the LSM hooks as with dummy). Then > CONFIG_SECURITY=n will yield the same result as CONFIG_SECURITY=y w/o > any further options. (cc Chris Wright and linux-security-module list) s/same result/same user-visible behavior/
As discussed above, this is operating as intended: the stated configuration does not have capabilities support, so trying to "KEEP" them doesn't make sense.
I just fell into the same trap, taking an existing .config from 2.6.25 and building it with 2.6.26-rc3. I ended up with the same configuration options being disabled and dhclient not working. Maybe we have a common history for the .config. Mine is based on a Ubuntu configuration. Maybe this is a stupid configuration and the kernel is doing the correct thing. But is it possible to help people not fall into this trap?
Regressions list annotation: Handled-By : "Andrew G. Morgan" <morgan@kernel.org> Patch : http://lkml.org/lkml/2008/6/10/9
fixed by commit 8cdbc2b9826b3543fecff2f6d6400fa77b21ffdd