Bug 10748
Summary: | dhclient fails to run; capabilities error | ||
---|---|---|---|
Product: | Networking | Reporter: | Amit Shah (amitshah) |
Component: | IPV4 | Assignee: | Stephen Hemminger (stephen) |
Status: | CLOSED CODE_FIX | ||
Severity: | normal | CC: | bunk, morgan |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.26-rc2 | Subsystem: | |
Regression: | Yes | Bisected commit-id: | |
Bug Depends on: | |||
Bug Blocks: | 10492 | ||
Attachments: | Config |
Description
Amit Shah
2008-05-19 06:25:00 UTC
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 |