2007-10-16 02:27:45

by Serge E. Hallyn

[permalink] [raw]
Subject: [PATCH 1/2 -mm] capabilities: clean up file capability reading

This patch is a simple cleanup which should probably be
applied to -mm (assuming I haven't messed it up). The next
patch is an experimental patch which will require userspace
support and is just RFC at this point.

>From 9fc0782de6e1287aaeebe8ad653b008f09b22c11 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Mon, 15 Oct 2007 17:33:24 -0400
Subject: [PATCH 1/2] capabilities: clean up file capability reading

Simplify the vfs_cap_data structure.

Also fix get_file_caps which was declaring
__le32 v1caps[XATTR_CAPS_SZ] on the stack, but
XATTR_CAPS_SZ is already * sizeof(__le32).

Signed-off-by: Serge E. Hallyn <[email protected]>
---
include/linux/capability.h | 6 ++----
security/commoncap.c | 23 +++++++++++++++--------
2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/include/linux/capability.h b/include/linux/capability.h
index 7a8d7ad..bb017ed 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -56,10 +56,8 @@ typedef struct __user_cap_data_struct {

struct vfs_cap_data {
__u32 magic_etc; /* Little endian */
- struct {
- __u32 permitted; /* Little endian */
- __u32 inheritable; /* Little endian */
- } data[1];
+ __u32 permitted; /* Little endian */
+ __u32 inheritable; /* Little endian */
};

#ifdef __KERNEL__
diff --git a/security/commoncap.c b/security/commoncap.c
index 43f9027..542bbe9 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -190,7 +190,8 @@ int cap_inode_killpriv(struct dentry *dentry)
return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
}

-static inline int cap_from_disk(__le32 *caps, struct linux_binprm *bprm,
+static inline int cap_from_disk(struct vfs_cap_data *caps,
+ struct linux_binprm *bprm,
int size)
{
__u32 magic_etc;
@@ -198,7 +199,7 @@ static inline int cap_from_disk(__le32 *caps, struct linux_binprm *bprm,
if (size != XATTR_CAPS_SZ)
return -EINVAL;

- magic_etc = le32_to_cpu(caps[0]);
+ magic_etc = le32_to_cpu(caps->magic_etc);

switch ((magic_etc & VFS_CAP_REVISION_MASK)) {
case VFS_CAP_REVISION:
@@ -206,8 +207,8 @@ static inline int cap_from_disk(__le32 *caps, struct linux_binprm *bprm,
bprm->cap_effective = true;
else
bprm->cap_effective = false;
- bprm->cap_permitted = to_cap_t( le32_to_cpu(caps[1]) );
- bprm->cap_inheritable = to_cap_t( le32_to_cpu(caps[2]) );
+ bprm->cap_permitted = to_cap_t( le32_to_cpu(caps->permitted) );
+ bprm->cap_inheritable = to_cap_t( le32_to_cpu(caps->inheritable) );
return 0;
default:
return -EINVAL;
@@ -219,7 +220,7 @@ static int get_file_caps(struct linux_binprm *bprm)
{
struct dentry *dentry;
int rc = 0;
- __le32 v1caps[XATTR_CAPS_SZ];
+ struct vfs_cap_data incaps;
struct inode *inode;

if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
@@ -232,8 +233,14 @@ static int get_file_caps(struct linux_binprm *bprm)
if (!inode->i_op || !inode->i_op->getxattr)
goto out;

- rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, &v1caps,
- XATTR_CAPS_SZ);
+ rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
+ if (rc > 0) {
+ if (rc == XATTR_CAPS_SZ)
+ rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS,
+ &incaps, XATTR_CAPS_SZ);
+ else
+ rc = -EINVAL;
+ }
if (rc == -ENODATA || rc == -EOPNOTSUPP) {
/* no data, that's ok */
rc = 0;
@@ -242,7 +249,7 @@ static int get_file_caps(struct linux_binprm *bprm)
if (rc < 0)
goto out;

- rc = cap_from_disk(v1caps, bprm, rc);
+ rc = cap_from_disk(&incaps, bprm, rc);
if (rc)
printk(KERN_NOTICE "%s: cap_from_disk returned %d for %s\n",
__FUNCTION__, rc, bprm->filename);
--
1.5.1.1.GIT


2007-10-16 02:31:18

by Serge E. Hallyn

[permalink] [raw]
Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

>From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Mon, 15 Oct 2007 20:57:52 -0400
Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

We are out of capabilities in the 32-bit capability fields, and
several users could make use of additional capabilities.
Convert the capabilities to 64-bits, change the capability
version number accordingly, and convert the file capability
code to handle both 32-bit and 64-bit file capability xattrs.

It might seem desirable to also implement back-compatibility
to read 32-bit caps from userspace, but that becomes
problematic with capget, as capget could return valid info
for processes not using high bits, but would have to return
-EINVAL for those which were.

So with this patch, libcap would need to be updated to make
use of capset/capget.

Signed-off-by: Serge E. Hallyn <[email protected]>
---
fs/proc/array.c | 6 +++---
include/linux/capability.h | 29 ++++++++++++++++++++---------
security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
3 files changed, 52 insertions(+), 20 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 3f4d824..c8ea46d 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)

static inline char *task_cap(struct task_struct *p, char *buffer)
{
- return buffer + sprintf(buffer, "CapInh:\t%016x\n"
- "CapPrm:\t%016x\n"
- "CapEff:\t%016x\n",
+ return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
+ "CapPrm:\t%016lx\n"
+ "CapEff:\t%016lx\n",
cap_t(p->cap_inheritable),
cap_t(p->cap_permitted),
cap_t(p->cap_effective));
diff --git a/include/linux/capability.h b/include/linux/capability.h
index bb017ed..a3da4b9 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -29,7 +29,7 @@ struct task_struct;
library since the draft standard requires the use of malloc/free
etc.. */

-#define _LINUX_CAPABILITY_VERSION 0x19980330
+#define _LINUX_CAPABILITY_VERSION 0x20071015

typedef struct __user_cap_header_struct {
__u32 version;
@@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
} __user *cap_user_header_t;

typedef struct __user_cap_data_struct {
- __u32 effective;
- __u32 permitted;
- __u32 inheritable;
+ __u64 effective;
+ __u64 permitted;
+ __u64 inheritable;
} __user *cap_user_data_t;

#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

-#define XATTR_CAPS_SZ (3*sizeof(__le32))
+#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
+#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
#define VFS_CAP_REVISION_MASK 0xFF000000
#define VFS_CAP_REVISION_1 0x01000000
+#define VFS_CAP_REVISION_2 0x02000000

-#define VFS_CAP_REVISION VFS_CAP_REVISION_1
+#define VFS_CAP_REVISION VFS_CAP_REVISION_2
+#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2

#define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x000001

-struct vfs_cap_data {
+struct vfs_cap_data_v1 {
__u32 magic_etc; /* Little endian */
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
};

+struct vfs_cap_data_v2 {
+ __u32 magic_etc; /* Little endian */
+ __u64 permitted; /* Little endian */
+ __u64 inheritable; /* Little endian */
+};
+
+typedef struct vfs_cap_data_v2 vfs_cap_data;
+
#ifdef __KERNEL__

/* #define STRICT_CAP_T_TYPECHECKS */
@@ -67,12 +78,12 @@ struct vfs_cap_data {
#ifdef STRICT_CAP_T_TYPECHECKS

typedef struct kernel_cap_struct {
- __u32 cap;
+ __u64 cap;
} kernel_cap_t;

#else

-typedef __u32 kernel_cap_t;
+typedef __u64 kernel_cap_t;

#endif

diff --git a/security/commoncap.c b/security/commoncap.c
index 542bbe9..2cca843 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -190,25 +190,46 @@ int cap_inode_killpriv(struct dentry *dentry)
return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
}

-static inline int cap_from_disk(struct vfs_cap_data *caps,
+union vfs_cap_union {
+ struct vfs_cap_data_v1 v1;
+ struct vfs_cap_data_v2 v2;
+};
+
+static inline int cap_from_disk(union vfs_cap_union *caps,
struct linux_binprm *bprm,
int size)
{
__u32 magic_etc;

- if (size != XATTR_CAPS_SZ)
+ if (size != XATTR_CAPS_SZ_1 && size != XATTR_CAPS_SZ_2)
return -EINVAL;

- magic_etc = le32_to_cpu(caps->magic_etc);
+ magic_etc = le32_to_cpu(caps->v1.magic_etc);

switch ((magic_etc & VFS_CAP_REVISION_MASK)) {
- case VFS_CAP_REVISION:
+ case VFS_CAP_REVISION_1:
+ if (size != XATTR_CAPS_SZ_1)
+ return -EINVAL;
+ if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
+ bprm->cap_effective = true;
+ else
+ bprm->cap_effective = false;
+ bprm->cap_permitted = to_cap_t(
+ (__u64) le32_to_cpu(caps->v1.permitted) );
+ bprm->cap_inheritable = to_cap_t(
+ (__u64) le32_to_cpu(caps->v1.inheritable) );
+ return 0;
+ case VFS_CAP_REVISION_2:
+ if (size != XATTR_CAPS_SZ_2)
+ return -EINVAL;
if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
bprm->cap_effective = true;
else
bprm->cap_effective = false;
- bprm->cap_permitted = to_cap_t( le32_to_cpu(caps->permitted) );
- bprm->cap_inheritable = to_cap_t( le32_to_cpu(caps->inheritable) );
+ bprm->cap_permitted = to_cap_t(
+ le64_to_cpu(caps->v2.permitted) );
+ bprm->cap_inheritable = to_cap_t(
+ le64_to_cpu(caps->v2.inheritable) );
return 0;
default:
return -EINVAL;
@@ -220,7 +241,7 @@ static int get_file_caps(struct linux_binprm *bprm)
{
struct dentry *dentry;
int rc = 0;
- struct vfs_cap_data incaps;
+ union vfs_cap_union incaps;
struct inode *inode;

if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
@@ -235,7 +256,7 @@ static int get_file_caps(struct linux_binprm *bprm)

rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
if (rc > 0) {
- if (rc == XATTR_CAPS_SZ)
+ if (rc == XATTR_CAPS_SZ_2 || rc == XATTR_CAPS_SZ_1)
rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS,
&incaps, XATTR_CAPS_SZ);
else
--
1.5.1.1.GIT

2007-10-16 14:31:22

by Stephen Smalley

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote:
> >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <[email protected]>
> Date: Mon, 15 Oct 2007 20:57:52 -0400
> Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
>
> We are out of capabilities in the 32-bit capability fields, and
> several users could make use of additional capabilities.
> Convert the capabilities to 64-bits, change the capability
> version number accordingly, and convert the file capability
> code to handle both 32-bit and 64-bit file capability xattrs.
>
> It might seem desirable to also implement back-compatibility
> to read 32-bit caps from userspace, but that becomes
> problematic with capget, as capget could return valid info
> for processes not using high bits, but would have to return
> -EINVAL for those which were.
>
> So with this patch, libcap would need to be updated to make
> use of capset/capget.
>
> Signed-off-by: Serge E. Hallyn <[email protected]>
> ---
> fs/proc/array.c | 6 +++---
> include/linux/capability.h | 29 ++++++++++++++++++++---------
> security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
> 3 files changed, 52 insertions(+), 20 deletions(-)
>
> diff --git a/fs/proc/array.c b/fs/proc/array.c
> index 3f4d824..c8ea46d 100644
> --- a/fs/proc/array.c
> +++ b/fs/proc/array.c
> @@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)
>
> static inline char *task_cap(struct task_struct *p, char *buffer)
> {
> - return buffer + sprintf(buffer, "CapInh:\t%016x\n"
> - "CapPrm:\t%016x\n"
> - "CapEff:\t%016x\n",
> + return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
> + "CapPrm:\t%016lx\n"
> + "CapEff:\t%016lx\n",
> cap_t(p->cap_inheritable),
> cap_t(p->cap_permitted),
> cap_t(p->cap_effective));
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index bb017ed..a3da4b9 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -29,7 +29,7 @@ struct task_struct;
> library since the draft standard requires the use of malloc/free
> etc.. */
>
> -#define _LINUX_CAPABILITY_VERSION 0x19980330
> +#define _LINUX_CAPABILITY_VERSION 0x20071015
>
> typedef struct __user_cap_header_struct {
> __u32 version;
> @@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
> } __user *cap_user_header_t;
>
> typedef struct __user_cap_data_struct {
> - __u32 effective;
> - __u32 permitted;
> - __u32 inheritable;
> + __u64 effective;
> + __u64 permitted;
> + __u64 inheritable;
> } __user *cap_user_data_t;
>
> #define XATTR_CAPS_SUFFIX "capability"
> #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
>
> -#define XATTR_CAPS_SZ (3*sizeof(__le32))
> +#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
> +#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
> #define VFS_CAP_REVISION_MASK 0xFF000000
> #define VFS_CAP_REVISION_1 0x01000000
> +#define VFS_CAP_REVISION_2 0x02000000
>
> -#define VFS_CAP_REVISION VFS_CAP_REVISION_1
> +#define VFS_CAP_REVISION VFS_CAP_REVISION_2
> +#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2
>
> #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
> #define VFS_CAP_FLAGS_EFFECTIVE 0x000001
>
> -struct vfs_cap_data {
> +struct vfs_cap_data_v1 {
> __u32 magic_etc; /* Little endian */
> __u32 permitted; /* Little endian */
> __u32 inheritable; /* Little endian */
> };
>
> +struct vfs_cap_data_v2 {
> + __u32 magic_etc; /* Little endian */
> + __u64 permitted; /* Little endian */
> + __u64 inheritable; /* Little endian */
> +};
> +
> +typedef struct vfs_cap_data_v2 vfs_cap_data;
> +
> #ifdef __KERNEL__
>
> /* #define STRICT_CAP_T_TYPECHECKS */
> @@ -67,12 +78,12 @@ struct vfs_cap_data {
> #ifdef STRICT_CAP_T_TYPECHECKS
>
> typedef struct kernel_cap_struct {
> - __u32 cap;
> + __u64 cap;
> } kernel_cap_t;
>
> #else
>
> -typedef __u32 kernel_cap_t;
> +typedef __u64 kernel_cap_t;
>
> #endif

Don't you need to update CAP_TO_MASK() too?
And, of course, SELinux task_has_capability() will then need to deal
with higher capabilities differently, most likely by mapping them to
permissions in a new class and access vector.

> diff --git a/security/commoncap.c b/security/commoncap.c
> index 542bbe9..2cca843 100644
> --- a/security/commoncap.c
> +++ b/security/commoncap.c
> @@ -190,25 +190,46 @@ int cap_inode_killpriv(struct dentry *dentry)
> return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
> }
>
> -static inline int cap_from_disk(struct vfs_cap_data *caps,
> +union vfs_cap_union {
> + struct vfs_cap_data_v1 v1;
> + struct vfs_cap_data_v2 v2;
> +};
> +
> +static inline int cap_from_disk(union vfs_cap_union *caps,
> struct linux_binprm *bprm,
> int size)
> {
> __u32 magic_etc;
>
> - if (size != XATTR_CAPS_SZ)
> + if (size != XATTR_CAPS_SZ_1 && size != XATTR_CAPS_SZ_2)
> return -EINVAL;
>
> - magic_etc = le32_to_cpu(caps->magic_etc);
> + magic_etc = le32_to_cpu(caps->v1.magic_etc);
>
> switch ((magic_etc & VFS_CAP_REVISION_MASK)) {
> - case VFS_CAP_REVISION:
> + case VFS_CAP_REVISION_1:
> + if (size != XATTR_CAPS_SZ_1)
> + return -EINVAL;
> + if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
> + bprm->cap_effective = true;
> + else
> + bprm->cap_effective = false;
> + bprm->cap_permitted = to_cap_t(
> + (__u64) le32_to_cpu(caps->v1.permitted) );
> + bprm->cap_inheritable = to_cap_t(
> + (__u64) le32_to_cpu(caps->v1.inheritable) );
> + return 0;
> + case VFS_CAP_REVISION_2:
> + if (size != XATTR_CAPS_SZ_2)
> + return -EINVAL;
> if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
> bprm->cap_effective = true;
> else
> bprm->cap_effective = false;
> - bprm->cap_permitted = to_cap_t( le32_to_cpu(caps->permitted) );
> - bprm->cap_inheritable = to_cap_t( le32_to_cpu(caps->inheritable) );
> + bprm->cap_permitted = to_cap_t(
> + le64_to_cpu(caps->v2.permitted) );
> + bprm->cap_inheritable = to_cap_t(
> + le64_to_cpu(caps->v2.inheritable) );
> return 0;
> default:
> return -EINVAL;
> @@ -220,7 +241,7 @@ static int get_file_caps(struct linux_binprm *bprm)
> {
> struct dentry *dentry;
> int rc = 0;
> - struct vfs_cap_data incaps;
> + union vfs_cap_union incaps;
> struct inode *inode;
>
> if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
> @@ -235,7 +256,7 @@ static int get_file_caps(struct linux_binprm *bprm)
>
> rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
> if (rc > 0) {
> - if (rc == XATTR_CAPS_SZ)
> + if (rc == XATTR_CAPS_SZ_2 || rc == XATTR_CAPS_SZ_1)
> rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS,
> &incaps, XATTR_CAPS_SZ);
> else
--
Stephen Smalley
National Security Agency

2007-10-16 18:48:35

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Stephen Smalley ([email protected]):
> On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote:
> > >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[email protected]>
> > Date: Mon, 15 Oct 2007 20:57:52 -0400
> > Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
> >
> > We are out of capabilities in the 32-bit capability fields, and
> > several users could make use of additional capabilities.
> > Convert the capabilities to 64-bits, change the capability
> > version number accordingly, and convert the file capability
> > code to handle both 32-bit and 64-bit file capability xattrs.
> >
> > It might seem desirable to also implement back-compatibility
> > to read 32-bit caps from userspace, but that becomes
> > problematic with capget, as capget could return valid info
> > for processes not using high bits, but would have to return
> > -EINVAL for those which were.
> >
> > So with this patch, libcap would need to be updated to make
> > use of capset/capget.
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > ---
> > fs/proc/array.c | 6 +++---
> > include/linux/capability.h | 29 ++++++++++++++++++++---------
> > security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
> > 3 files changed, 52 insertions(+), 20 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index 3f4d824..c8ea46d 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)
> >
> > static inline char *task_cap(struct task_struct *p, char *buffer)
> > {
> > - return buffer + sprintf(buffer, "CapInh:\t%016x\n"
> > - "CapPrm:\t%016x\n"
> > - "CapEff:\t%016x\n",
> > + return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
> > + "CapPrm:\t%016lx\n"
> > + "CapEff:\t%016lx\n",
> > cap_t(p->cap_inheritable),
> > cap_t(p->cap_permitted),
> > cap_t(p->cap_effective));
> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> > index bb017ed..a3da4b9 100644
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > @@ -29,7 +29,7 @@ struct task_struct;
> > library since the draft standard requires the use of malloc/free
> > etc.. */
> >
> > -#define _LINUX_CAPABILITY_VERSION 0x19980330
> > +#define _LINUX_CAPABILITY_VERSION 0x20071015
> >
> > typedef struct __user_cap_header_struct {
> > __u32 version;
> > @@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
> > } __user *cap_user_header_t;
> >
> > typedef struct __user_cap_data_struct {
> > - __u32 effective;
> > - __u32 permitted;
> > - __u32 inheritable;
> > + __u64 effective;
> > + __u64 permitted;
> > + __u64 inheritable;
> > } __user *cap_user_data_t;
> >
> > #define XATTR_CAPS_SUFFIX "capability"
> > #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> >
> > -#define XATTR_CAPS_SZ (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
> > #define VFS_CAP_REVISION_MASK 0xFF000000
> > #define VFS_CAP_REVISION_1 0x01000000
> > +#define VFS_CAP_REVISION_2 0x02000000
> >
> > -#define VFS_CAP_REVISION VFS_CAP_REVISION_1
> > +#define VFS_CAP_REVISION VFS_CAP_REVISION_2
> > +#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2
> >
> > #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
> > #define VFS_CAP_FLAGS_EFFECTIVE 0x000001
> >
> > -struct vfs_cap_data {
> > +struct vfs_cap_data_v1 {
> > __u32 magic_etc; /* Little endian */
> > __u32 permitted; /* Little endian */
> > __u32 inheritable; /* Little endian */
> > };
> >
> > +struct vfs_cap_data_v2 {
> > + __u32 magic_etc; /* Little endian */
> > + __u64 permitted; /* Little endian */
> > + __u64 inheritable; /* Little endian */
> > +};
> > +
> > +typedef struct vfs_cap_data_v2 vfs_cap_data;
> > +
> > #ifdef __KERNEL__
> >
> > /* #define STRICT_CAP_T_TYPECHECKS */
> > @@ -67,12 +78,12 @@ struct vfs_cap_data {
> > #ifdef STRICT_CAP_T_TYPECHECKS
> >
> > typedef struct kernel_cap_struct {
> > - __u32 cap;
> > + __u64 cap;
> > } kernel_cap_t;
> >
> > #else
> >
> > -typedef __u32 kernel_cap_t;
> > +typedef __u64 kernel_cap_t;
> >
> > #endif
>
> Don't you need to update CAP_TO_MASK() too?

Yeah, I'm afraid so.

> And, of course, SELinux task_has_capability() will then need to deal
> with higher capabilities differently, most likely by mapping them to
> permissions in a new class and access vector.

I saw your other email about this so will watch that thread.

thanks,
-serge

2007-10-16 21:42:23

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Stephen Smalley ([email protected]):
> On Mon, 2007-10-15 at 21:31 -0500, Serge E. Hallyn wrote:
> > >From 7dd503c612afcb86b3165602ab264e2e9493b4bf Mon Sep 17 00:00:00 2001
> > From: Serge E. Hallyn <[email protected]>
> > Date: Mon, 15 Oct 2007 20:57:52 -0400
> > Subject: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities
> >
> > We are out of capabilities in the 32-bit capability fields, and
> > several users could make use of additional capabilities.
> > Convert the capabilities to 64-bits, change the capability
> > version number accordingly, and convert the file capability
> > code to handle both 32-bit and 64-bit file capability xattrs.
> >
> > It might seem desirable to also implement back-compatibility
> > to read 32-bit caps from userspace, but that becomes
> > problematic with capget, as capget could return valid info
> > for processes not using high bits, but would have to return
> > -EINVAL for those which were.
> >
> > So with this patch, libcap would need to be updated to make
> > use of capset/capget.
> >
> > Signed-off-by: Serge E. Hallyn <[email protected]>
> > ---
> > fs/proc/array.c | 6 +++---
> > include/linux/capability.h | 29 ++++++++++++++++++++---------
> > security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
> > 3 files changed, 52 insertions(+), 20 deletions(-)
> >
> > diff --git a/fs/proc/array.c b/fs/proc/array.c
> > index 3f4d824..c8ea46d 100644
> > --- a/fs/proc/array.c
> > +++ b/fs/proc/array.c
> > @@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)
> >
> > static inline char *task_cap(struct task_struct *p, char *buffer)
> > {
> > - return buffer + sprintf(buffer, "CapInh:\t%016x\n"
> > - "CapPrm:\t%016x\n"
> > - "CapEff:\t%016x\n",
> > + return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
> > + "CapPrm:\t%016lx\n"
> > + "CapEff:\t%016lx\n",
> > cap_t(p->cap_inheritable),
> > cap_t(p->cap_permitted),
> > cap_t(p->cap_effective));
> > diff --git a/include/linux/capability.h b/include/linux/capability.h
> > index bb017ed..a3da4b9 100644
> > --- a/include/linux/capability.h
> > +++ b/include/linux/capability.h
> > @@ -29,7 +29,7 @@ struct task_struct;
> > library since the draft standard requires the use of malloc/free
> > etc.. */
> >
> > -#define _LINUX_CAPABILITY_VERSION 0x19980330
> > +#define _LINUX_CAPABILITY_VERSION 0x20071015
> >
> > typedef struct __user_cap_header_struct {
> > __u32 version;
> > @@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
> > } __user *cap_user_header_t;
> >
> > typedef struct __user_cap_data_struct {
> > - __u32 effective;
> > - __u32 permitted;
> > - __u32 inheritable;
> > + __u64 effective;
> > + __u64 permitted;
> > + __u64 inheritable;
> > } __user *cap_user_data_t;
> >
> > #define XATTR_CAPS_SUFFIX "capability"
> > #define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX
> >
> > -#define XATTR_CAPS_SZ (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
> > +#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
> > #define VFS_CAP_REVISION_MASK 0xFF000000
> > #define VFS_CAP_REVISION_1 0x01000000
> > +#define VFS_CAP_REVISION_2 0x02000000
> >
> > -#define VFS_CAP_REVISION VFS_CAP_REVISION_1
> > +#define VFS_CAP_REVISION VFS_CAP_REVISION_2
> > +#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2
> >
> > #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
> > #define VFS_CAP_FLAGS_EFFECTIVE 0x000001
> >
> > -struct vfs_cap_data {
> > +struct vfs_cap_data_v1 {
> > __u32 magic_etc; /* Little endian */
> > __u32 permitted; /* Little endian */
> > __u32 inheritable; /* Little endian */
> > };
> >
> > +struct vfs_cap_data_v2 {
> > + __u32 magic_etc; /* Little endian */
> > + __u64 permitted; /* Little endian */
> > + __u64 inheritable; /* Little endian */
> > +};
> > +
> > +typedef struct vfs_cap_data_v2 vfs_cap_data;
> > +
> > #ifdef __KERNEL__
> >
> > /* #define STRICT_CAP_T_TYPECHECKS */
> > @@ -67,12 +78,12 @@ struct vfs_cap_data {
> > #ifdef STRICT_CAP_T_TYPECHECKS
> >
> > typedef struct kernel_cap_struct {
> > - __u32 cap;
> > + __u64 cap;
> > } kernel_cap_t;
> >
> > #else
> >
> > -typedef __u32 kernel_cap_t;
> > +typedef __u64 kernel_cap_t;
> >
> > #endif
>
> Don't you need to update CAP_TO_MASK() too?

Thanks for catching that.

New patch appended - I'll leave the selinux patch out until there is
more comment on the selinux list?

To properly test this the libcap code will need to be updated first,
which I'm looking at now...

thanks,
-serge


>From 276a6f84f10a627832c067d8e039aafffaca67a1 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn <[email protected]>
Date: Mon, 15 Oct 2007 20:57:52 -0400
Subject: [PATCH 2/2] capabilities: implement 64-bit capabilities

We are out of capabilities in the 32-bit capability fields, and
several users could make use of additional capabilities.
Convert the capabilities to 64-bits, change the capability
version number accordingly, and convert the file capability
code to handle both 32-bit and 64-bit file capability xattrs.

It might seem desirable to also implement back-compatibility
to read 32-bit caps from userspace, but that becomes
problematic with capget, as capget could return valid info
for processes not using high bits, but would have to return
-EINVAL for those which were.

Changelog:
Oct 16: fix the CAP_TO_MASK definition

Signed-off-by: Serge E. Hallyn <[email protected]>
---
fs/proc/array.c | 6 +++---
include/linux/capability.h | 31 +++++++++++++++++++++----------
security/commoncap.c | 37 +++++++++++++++++++++++++++++--------
3 files changed, 53 insertions(+), 21 deletions(-)

diff --git a/fs/proc/array.c b/fs/proc/array.c
index 3f4d824..c8ea46d 100644
--- a/fs/proc/array.c
+++ b/fs/proc/array.c
@@ -288,9 +288,9 @@ static inline char *task_sig(struct task_struct *p, char *buffer)

static inline char *task_cap(struct task_struct *p, char *buffer)
{
- return buffer + sprintf(buffer, "CapInh:\t%016x\n"
- "CapPrm:\t%016x\n"
- "CapEff:\t%016x\n",
+ return buffer + sprintf(buffer, "CapInh:\t%016lx\n"
+ "CapPrm:\t%016lx\n"
+ "CapEff:\t%016lx\n",
cap_t(p->cap_inheritable),
cap_t(p->cap_permitted),
cap_t(p->cap_effective));
diff --git a/include/linux/capability.h b/include/linux/capability.h
index bb017ed..316c4c3 100644
--- a/include/linux/capability.h
+++ b/include/linux/capability.h
@@ -29,7 +29,7 @@ struct task_struct;
library since the draft standard requires the use of malloc/free
etc.. */

-#define _LINUX_CAPABILITY_VERSION 0x19980330
+#define _LINUX_CAPABILITY_VERSION 0x20071015

typedef struct __user_cap_header_struct {
__u32 version;
@@ -37,29 +37,40 @@ typedef struct __user_cap_header_struct {
} __user *cap_user_header_t;

typedef struct __user_cap_data_struct {
- __u32 effective;
- __u32 permitted;
- __u32 inheritable;
+ __u64 effective;
+ __u64 permitted;
+ __u64 inheritable;
} __user *cap_user_data_t;

#define XATTR_CAPS_SUFFIX "capability"
#define XATTR_NAME_CAPS XATTR_SECURITY_PREFIX XATTR_CAPS_SUFFIX

-#define XATTR_CAPS_SZ (3*sizeof(__le32))
+#define XATTR_CAPS_SZ_1 (3*sizeof(__le32))
+#define XATTR_CAPS_SZ_2 (2*sizeof(__le64) + sizeof(__le32))
#define VFS_CAP_REVISION_MASK 0xFF000000
#define VFS_CAP_REVISION_1 0x01000000
+#define VFS_CAP_REVISION_2 0x02000000

-#define VFS_CAP_REVISION VFS_CAP_REVISION_1
+#define VFS_CAP_REVISION VFS_CAP_REVISION_2
+#define XATTR_CAPS_SZ XATTR_CAPS_SZ_2

#define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x000001

-struct vfs_cap_data {
+struct vfs_cap_data_v1 {
__u32 magic_etc; /* Little endian */
__u32 permitted; /* Little endian */
__u32 inheritable; /* Little endian */
};

+struct vfs_cap_data_v2 {
+ __u32 magic_etc; /* Little endian */
+ __u64 permitted; /* Little endian */
+ __u64 inheritable; /* Little endian */
+};
+
+typedef struct vfs_cap_data_v2 vfs_cap_data;
+
#ifdef __KERNEL__

/* #define STRICT_CAP_T_TYPECHECKS */
@@ -67,12 +78,12 @@ struct vfs_cap_data {
#ifdef STRICT_CAP_T_TYPECHECKS

typedef struct kernel_cap_struct {
- __u32 cap;
+ __u64 cap;
} kernel_cap_t;

#else

-typedef __u32 kernel_cap_t;
+typedef __u64 kernel_cap_t;

#endif

@@ -330,7 +341,7 @@ typedef __u32 kernel_cap_t;
#define CAP_INIT_EFF_SET to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
#define CAP_INIT_INH_SET to_cap_t(0)

-#define CAP_TO_MASK(x) (1 << (x))
+#define CAP_TO_MASK(x) (1ULL << (x))
#define cap_raise(c, flag) (cap_t(c) |= CAP_TO_MASK(flag))
#define cap_lower(c, flag) (cap_t(c) &= ~CAP_TO_MASK(flag))
#define cap_raised(c, flag) (cap_t(c) & CAP_TO_MASK(flag))
diff --git a/security/commoncap.c b/security/commoncap.c
index 542bbe9..2cca843 100644
--- a/security/commoncap.c
+++ b/security/commoncap.c
@@ -190,25 +190,46 @@ int cap_inode_killpriv(struct dentry *dentry)
return inode->i_op->removexattr(dentry, XATTR_NAME_CAPS);
}

-static inline int cap_from_disk(struct vfs_cap_data *caps,
+union vfs_cap_union {
+ struct vfs_cap_data_v1 v1;
+ struct vfs_cap_data_v2 v2;
+};
+
+static inline int cap_from_disk(union vfs_cap_union *caps,
struct linux_binprm *bprm,
int size)
{
__u32 magic_etc;

- if (size != XATTR_CAPS_SZ)
+ if (size != XATTR_CAPS_SZ_1 && size != XATTR_CAPS_SZ_2)
return -EINVAL;

- magic_etc = le32_to_cpu(caps->magic_etc);
+ magic_etc = le32_to_cpu(caps->v1.magic_etc);

switch ((magic_etc & VFS_CAP_REVISION_MASK)) {
- case VFS_CAP_REVISION:
+ case VFS_CAP_REVISION_1:
+ if (size != XATTR_CAPS_SZ_1)
+ return -EINVAL;
+ if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
+ bprm->cap_effective = true;
+ else
+ bprm->cap_effective = false;
+ bprm->cap_permitted = to_cap_t(
+ (__u64) le32_to_cpu(caps->v1.permitted) );
+ bprm->cap_inheritable = to_cap_t(
+ (__u64) le32_to_cpu(caps->v1.inheritable) );
+ return 0;
+ case VFS_CAP_REVISION_2:
+ if (size != XATTR_CAPS_SZ_2)
+ return -EINVAL;
if (magic_etc & VFS_CAP_FLAGS_EFFECTIVE)
bprm->cap_effective = true;
else
bprm->cap_effective = false;
- bprm->cap_permitted = to_cap_t( le32_to_cpu(caps->permitted) );
- bprm->cap_inheritable = to_cap_t( le32_to_cpu(caps->inheritable) );
+ bprm->cap_permitted = to_cap_t(
+ le64_to_cpu(caps->v2.permitted) );
+ bprm->cap_inheritable = to_cap_t(
+ le64_to_cpu(caps->v2.inheritable) );
return 0;
default:
return -EINVAL;
@@ -220,7 +241,7 @@ static int get_file_caps(struct linux_binprm *bprm)
{
struct dentry *dentry;
int rc = 0;
- struct vfs_cap_data incaps;
+ union vfs_cap_union incaps;
struct inode *inode;

if (bprm->file->f_vfsmnt->mnt_flags & MNT_NOSUID) {
@@ -235,7 +256,7 @@ static int get_file_caps(struct linux_binprm *bprm)

rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS, NULL, 0);
if (rc > 0) {
- if (rc == XATTR_CAPS_SZ)
+ if (rc == XATTR_CAPS_SZ_2 || rc == XATTR_CAPS_SZ_1)
rc = inode->i_op->getxattr(dentry, XATTR_NAME_CAPS,
&incaps, XATTR_CAPS_SZ);
else
--
1.5.1.1.GIT

2007-10-18 01:07:21

by Andrew Morton

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

On Tue, 16 Oct 2007 16:41:59 -0500
"Serge E. Hallyn" <[email protected]> wrote:

> To properly test this the libcap code will need to be updated first,
> which I'm looking at now...

This seems fairly significant. I asusme that this patch won't break
presently-deployed libcap?

2007-10-18 02:59:37

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Andrew Morton ([email protected]):
> On Tue, 16 Oct 2007 16:41:59 -0500
> "Serge E. Hallyn" <[email protected]> wrote:
>
> > To properly test this the libcap code will need to be updated first,
> > which I'm looking at now...
>
> This seems fairly significant. I asusme that this patch won't break
> presently-deployed libcap?

It will break libcap. And I'm not sure of the right way to address it.
So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and
Kaigai.

We can introduce new capget64() and capset64() calls, and have
capget() return -EINVAL or -EAGAIN if a high bit would be needed to
accurately get the task's capabilities.

Or we can require a new libcap, since capget and capset aren't
required for most day-to-day function anyway.

I guess now that I've written this out, it seems pretty clear
that capget64() and capget64() are the way to go. Any objections?

thanks,
-serge

2007-10-18 03:14:14

by Casey Schaufler

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities


--- "Serge E. Hallyn" <[email protected]> wrote:

> Quoting Andrew Morton ([email protected]):
> > On Tue, 16 Oct 2007 16:41:59 -0500
> > "Serge E. Hallyn" <[email protected]> wrote:
> >
> > > To properly test this the libcap code will need to be updated first,
> > > which I'm looking at now...
> >
> > This seems fairly significant. I asusme that this patch won't break
> > presently-deployed libcap?
>
> It will break libcap. And I'm not sure of the right way to address it.
> So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and
> Kaigai.
>
> We can introduce new capget64() and capset64() calls, and have
> capget() return -EINVAL or -EAGAIN if a high bit would be needed to
> accurately get the task's capabilities.
>
> Or we can require a new libcap, since capget and capset aren't
> required for most day-to-day function anyway.
>
> I guess now that I've written this out, it seems pretty clear
> that capget64() and capget64() are the way to go. Any objections?

Not from me. Thank you.


Casey Schaufler
[email protected]

2007-10-18 03:26:05

by Andrew Morton

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

On Wed, 17 Oct 2007 21:59:20 -0500 "Serge E. Hallyn" <[email protected]> wrote:

> Quoting Andrew Morton ([email protected]):
> > On Tue, 16 Oct 2007 16:41:59 -0500
> > "Serge E. Hallyn" <[email protected]> wrote:
> >
> > > To properly test this the libcap code will need to be updated first,
> > > which I'm looking at now...
> >
> > This seems fairly significant. I asusme that this patch won't break
> > presently-deployed libcap?
>
> It will break libcap.

yikes, dropped!

> And I'm not sure of the right way to address it.
> So I was hoping to hear some ideas from Andrew Morgan, Chris Wright, and
> Kaigai.
>
> We can introduce new capget64() and capset64() calls, and have
> capget() return -EINVAL or -EAGAIN if a high bit would be needed to
> accurately get the task's capabilities.
>
> Or we can require a new libcap, since capget and capset aren't
> required for most day-to-day function anyway.
>
> I guess now that I've written this out, it seems pretty clear
> that capget64() and capget64() are the way to go. Any objections?

Sounds sane. New syscalls are cheap and it's clear separation.

2007-10-18 05:24:16

by Chris Wright

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

* Serge E. Hallyn ([email protected]) wrote:
> I guess now that I've written this out, it seems pretty clear
> that capget64() and capget64() are the way to go. Any objections?

How is capget64() different from capget() that supports 2 different
header->versions (I thought that was the whole point of the versioned,
rather opaque interface)? I don't object to a new syscall, but I don't
see why it's required to avoid breaking libcap.

thanks,
-chris

2007-10-18 12:50:42

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Chris Wright ([email protected]):
> * Serge E. Hallyn ([email protected]) wrote:
> > I guess now that I've written this out, it seems pretty clear
> > that capget64() and capget64() are the way to go. Any objections?
>
> How is capget64() different from capget() that supports 2 different
> header->versions (I thought that was the whole point of the versioned,
> rather opaque interface)? I don't object to a new syscall, but I don't
> see why it's required to avoid breaking libcap.

Hmm, I guess it *works*, it's just harder to explain the "inconsistent"
behavior. Now instead of saying "capget() will fail under certain
conditions while capget64() will always succeed", capget() will actually
fail under certain conditions only if you send in a certain header.

Again, once I've written it out, I guess it isn't *so* bad.

thanks,
-serge

2007-10-18 15:28:39

by Andrew G. Morgan

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Serge E. Hallyn wrote:
> Quoting Chris Wright ([email protected]):
>> * Serge E. Hallyn ([email protected]) wrote:
>>> I guess now that I've written this out, it seems pretty clear
>>> that capget64() and capget64() are the way to go. Any objections?
>> How is capget64() different from capget() that supports 2 different
>> header->versions (I thought that was the whole point of the versioned,
>> rather opaque interface)? I don't object to a new syscall, but I don't
>> see why it's required to avoid breaking libcap.
>
> Hmm, I guess it *works*, it's just harder to explain the "inconsistent"
> behavior. Now instead of saying "capget() will fail under certain
> conditions while capget64() will always succeed", capget() will actually
> fail under certain conditions only if you send in a certain header.
>
> Again, once I've written it out, I guess it isn't *so* bad.

[I'm just wading back into a mass of neglected email. Long story.]

Chris is right, this is precisely why the interface is versioned, and
there is at least one version of libcap that was written to support this
versioning scheme

cvs -z3
- -d:pserver:[email protected]:/cvsroot/linux-privs
co -r libcap-pre2 libcap

I'll try and unwind all the threads of email I've been neglecting and
have something useful to say over the next few days.

Cheers

Andrew

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.7 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHF3tj+bHCR3gb8jsRAhF1AJ9gfmUnO+O0YyzPLaqGVv++pZjvdgCgzz3J
+yF6CRASj8QVYArDydc84k8=
=K/Wb
-----END PGP SIGNATURE-----

2007-10-18 15:30:41

by Serge E. Hallyn

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

Quoting Andrew Morgan ([email protected]):
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Serge E. Hallyn wrote:
> > Quoting Chris Wright ([email protected]):
> >> * Serge E. Hallyn ([email protected]) wrote:
> >>> I guess now that I've written this out, it seems pretty clear
> >>> that capget64() and capget64() are the way to go. Any objections?
> >> How is capget64() different from capget() that supports 2 different
> >> header->versions (I thought that was the whole point of the versioned,
> >> rather opaque interface)? I don't object to a new syscall, but I don't
> >> see why it's required to avoid breaking libcap.
> >
> > Hmm, I guess it *works*, it's just harder to explain the "inconsistent"
> > behavior. Now instead of saying "capget() will fail under certain
> > conditions while capget64() will always succeed", capget() will actually
> > fail under certain conditions only if you send in a certain header.
> >
> > Again, once I've written it out, I guess it isn't *so* bad.
>
> [I'm just wading back into a mass of neglected email. Long story.]
>
> Chris is right, this is precisely why the interface is versioned, and
> there is at least one version of libcap that was written to support this
> versioning scheme

Ok - i actually didn't default to backward compatibility because I was
pretty sure you would object to it on the grounds that old userspace
might get unexpected behavior. But I guess since all high caps should be
new ones for new features, it'll require new userspace to exploit
anyway.

> cvs -z3
> - -d:pserver:[email protected]:/cvsroot/linux-privs
> co -r libcap-pre2 libcap
>
> I'll try and unwind all the threads of email I've been neglecting and
> have something useful to say over the next few days.

Thanks. I'll try to get a backward-compatible patch out today (again
just for rfc) If not today, at least tomorrow.

thanks,
-serge

2007-10-18 15:32:15

by Chris Wright

[permalink] [raw]
Subject: Re: [RFC] [PATCH 2/2] capabilities: implement 64-bit capabilities

* Serge E. Hallyn ([email protected]) wrote:
> Quoting Chris Wright ([email protected]):
> > * Serge E. Hallyn ([email protected]) wrote:
> > > I guess now that I've written this out, it seems pretty clear
> > > that capget64() and capget64() are the way to go. Any objections?
> >
> > How is capget64() different from capget() that supports 2 different
> > header->versions (I thought that was the whole point of the versioned,
> > rather opaque interface)? I don't object to a new syscall, but I don't
> > see why it's required to avoid breaking libcap.
>
> Hmm, I guess it *works*, it's just harder to explain the "inconsistent"
> behavior. Now instead of saying "capget() will fail under certain
> conditions while capget64() will always succeed", capget() will actually
> fail under certain conditions only if you send in a certain header.
>
> Again, once I've written it out, I guess it isn't *so* bad.

It's not really any different than issuing capget(0x19980330) (assuming
capget64 is different), and getting -EINVAL when the actual in-use
caps are > 32 bits wide. In either case the rules are the same --
old interface works fine as long as you don't have new caps involved.
Only advantage I see to using the extant interface is that the cap[sg]et
interface is already designed to be future-proof (albeit in an unusual
way compared with most other kernel syscalls).

thanks,
-chris