[PATCH 1/1] added code to export CAP_LAST_CAP in /proc/sys/kernel modeled after ngroups_max

[PATCH 1/1] added code to export CAP_LAST_CAP in /proc/sys/kernel modeled after ngroups_max

[Dan Ballard]

In response to a request by the Linux Plumbers about getting CAP_LAST_CAP exposed somehow, I talked to Lennart Poettering briefly and went ahead and added cap_last_cap to /proc/sys/kernel in a similar fashion as ngroups_max is exported.  The patch is simple and just adds another struct to the array of exported values in sysctl.c.

Signed-off-by: Dan Ballard <dan@mindstab.net>
---
 kernel/sysctl.c |    9 +++++++++
 1 files changed, 9 insertions(+), 0 deletions(-)

diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 11d65b5..0cef3c2 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -57,6 +57,7 @@
 #include <linux/pipe_fs_i.h>
 #include <linux/oom.h>
 #include <linux/kmod.h>
+#include <linux/capability.h>
 
 #include <asm/uaccess.h>
 #include <asm/processor.h>
@@ -134,6 +135,7 @@ static int minolduid;
 static int min_percpu_pagelist_fract = 8;
 
 static int ngroups_max = NGROUPS_MAX;
+static int cap_last_cap = CAP_LAST_CAP;
 
 #ifdef CONFIG_INOTIFY_USER
 #include <linux/inotify.h>
@@ -730,6 +732,13 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0444,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "cap_last_cap",
+		.data		= &cap_last_cap,
+		.maxlen		= sizeof(int),
+		.mode		= 0444,
+		.proc_handler	= proc_dointvec,
+	},
 #if defined(CONFIG_LOCKUP_DETECTOR)
 	{
 		.procname       = "watchdog",
-- 
1.7.4.1

Re: [PATCH 1/1] added code to export CAP_LAST_CAP in /proc/sys/kernel modeled after ngroups_max

[Andrew Morton]

On Wed, 12 Oct 2011 15:56:34 -0700
Dan Ballard <dan@mindstab.net> wrote:

> In response to a request by the Linux Plumbers about getting CAP_LAST_CAP exposed somehow, I talked to Lennart Poettering briefly and went ahead and added cap_last_cap to /proc/sys/kernel in a similar fashion as ngroups_max is exported.  The patch is simple and just adds another struct to the array of exported values in sysctl.c.
> 

The changelog should explain the reason for making this change, please.
People aren't going to remember some vague email thread five years
from now.

Also, please update the documentation.  Documentation/sysctl/kernel.txt
is a suitable place.  Lots of things in kern_table[] are undocumented,
but that's not a reason for the rest of us to suck as much as sched
developers :)

[PATCH 1/1] kernel/sysctl.c: Add cap_last_cap to /proc/sys/kernel

[Dan Ballard]

Userspace needs to know the highest valid capability of the running
kernel, which right now cannot reliably be retrieved from the header
files only.  The fact that this value cannot be determined properly
right now creates various problems for libraries compiled on newer
header files which are run on older kernels. They assume
capabilities are available which actually aren't.

Now the capability is exported in /proc/sys/kernel/cap_last_cap.

Signed-off-by: Dan Ballard <dan@mindstab.net>
---
 Documentation/sysctl/kernel.txt |    8 ++++++++
 kernel/sysctl.c                 |    9 +++++++++
 2 files changed, 17 insertions(+), 0 deletions(-)

diff --git a/Documentation/sysctl/kernel.txt b/Documentation/sysctl/kernel.txt
index 704e474..1f24636 100644
--- a/Documentation/sysctl/kernel.txt
+++ b/Documentation/sysctl/kernel.txt
@@ -24,6 +24,7 @@ show up in /proc/sys/kernel:
 - bootloader_type	     [ X86 only ]
 - bootloader_version	     [ X86 only ]
 - callhome		     [ S390 only ]
+- cap_last_cap
 - core_pattern
 - core_pipe_limit
 - core_uses_pid
@@ -155,6 +156,13 @@ on has a service contract with IBM.
 
 ==============================================================
 
+cap_last_cap
+
+Highest valid capability of the running kernel.  Exports
+CAP_LAST_CAP from the kernel.
+
+==============================================================
+
 core_pattern:
 
 core_pattern is used to specify a core dumpfile pattern name.
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 11d65b5..06455c0 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -57,6 +57,7 @@
 #include <linux/pipe_fs_i.h>
 #include <linux/oom.h>
 #include <linux/kmod.h>
+#include <linux/capability.h>
 
 #include <asm/uaccess.h>
 #include <asm/processor.h>
@@ -134,6 +135,7 @@ static int minolduid;
 static int min_percpu_pagelist_fract = 8;
 
 static int ngroups_max = NGROUPS_MAX;
+static int cap_last_cap = CAP_LAST_CAP;
 
 #ifdef CONFIG_INOTIFY_USER
 #include <linux/inotify.h>
@@ -730,6 +732,13 @@ static struct ctl_table kern_table[] = {
 		.mode		= 0444,
 		.proc_handler	= proc_dointvec,
 	},
+	{
+		.procname	= "cap_last_cap",
+		.data		= &cap_last_cap,
+		.maxlen		= sizeof(int),
+		.mode		= 0444,
+		.proc_handler	= proc_dointvec,
+	},
 #if defined(CONFIG_LOCKUP_DETECTOR)
 	{
 		.procname       = "watchdog",
-- 
1.7.2.5

Re: [PATCH 1/1] kernel/sysctl.c: Add cap_last_cap to /proc/sys/kernel

[Andrew Morton]

On Sat, 15 Oct 2011 07:50:05 -0700
Dan Ballard <dan@mindstab.net> wrote:

> Userspace needs to know the highest valid capability of the running
> kernel, which right now cannot reliably be retrieved from the header
> files only.  The fact that this value cannot be determined properly
> right now creates various problems for libraries compiled on newer
> header files which are run on older kernels. They assume
> capabilities are available which actually aren't.

Specfically, what libraries are we talking about here?

> Now the capability is exported in /proc/sys/kernel/cap_last_cap.

Ever the optimist: is there any way in which we can avoid 0444
permissions on this?

Re: [PATCH 1/1] kernel/sysctl.c: Add cap_last_cap to /proc/sys/kernel

[Lennart Poettering]

On Mon, 17.10.11 15:39, Andrew Morton (akpm@linux-foundation.org) wrote:

> 
> On Sat, 15 Oct 2011 07:50:05 -0700
> Dan Ballard <dan@mindstab.net> wrote:
> 
> > Userspace needs to know the highest valid capability of the running
> > kernel, which right now cannot reliably be retrieved from the header
> > files only.  The fact that this value cannot be determined properly
> > right now creates various problems for libraries compiled on newer
> > header files which are run on older kernels. They assume
> > capabilities are available which actually aren't.
> 
> Specfically, what libraries are we talking about here?

libcap-ng, for example. And we ran into the same problem with systemd too.
> 
> > Now the capability is exported in /proc/sys/kernel/cap_last_cap.
> 
> Ever the optimist: is there any way in which we can avoid 0444
> permissions on this?

Normal users should be able to query this value, and it's not a security
problem if they do. Hence 0444 appears to be the right setting to me.

Lennart

-- 
Lennart Poettering - Red Hat, Inc.