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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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- - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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? - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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] - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
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 0xFF00
> > #define VFS_CAP_REVISION_1 0x0100
> > +#define VFS_CAP_REVISION_2 0x0200
> >
> > -#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_EFFECTIVE0x01
> >
> > -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 */
> >
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 0xFF00
> > #define VFS_CAP_REVISION_1 0x0100
> > +#define VFS_CAP_REVISION_2 0x0200
> >
> > -#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_EFFECTIVE0x01
> >
> > -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 */
>
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_MASK0xFF00
> #define VFS_CAP_REVISION_1 0x0100
> +#define VFS_CAP_REVISION_2 0x0200
>
> -#define VFS_CAP_REVISION VFS_CAP_REVISION_1
> +#define VFS_CAP_REVISION VFS_CAP_REVISION_2
> +#define XATTR_CAPS_SZXATTR_CAPS_SZ_2
>
> #define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
> #define VFS_CAP_FLAGS_EFFECTIVE 0x01
>
> -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.
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_MASK0xFF00
#define VFS_CAP_REVISION_1 0x0100
+#define VFS_CAP_REVISION_2 0x0200
-#define VFS_CAP_REVISION VFS_CAP_REVISION_1
+#define VFS_CAP_REVISION VFS_CAP_REVISION_2
+#define XATTR_CAPS_SZXATTR_CAPS_SZ_2
#define VFS_CAP_FLAGS_MASK ~VFS_CAP_REVISION_MASK
#define VFS_CAP_FLAGS_EFFECTIVE 0x01
-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
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 0xFF00
#define VFS_CAP_REVISION_1 0x0100
+#define VFS_CAP_REVISION_2 0x0200
-#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_EFFECTIVE0x01
-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
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
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 0xFF00
#define VFS_CAP_REVISION_1 0x0100
+#define VFS_CAP_REVISION_2 0x0200
-#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_EFFECTIVE0x01
-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
[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 0xFF00
#define VFS_CAP_REVISION_1 0x0100
+#define VFS_CAP_REVISION_2 0x0200
-#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_EFFECTIVE0x01
-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);
+ mag
[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 0xFF00
#define VFS_CAP_REVISION_1 0x0100
+#define VFS_CAP_REVISION_2 0x0200
-#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_EFFECTIVE0x01
-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
