From: Oren Laadan <orenl@cs.columbia.edu>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: "Andrew G. Morgan" <morgan@kernel.org>,
Linux Containers <containers@lists.osdl.org>,
Alexey Dobriyan <adobriyan@gmail.com>,
David Howells <dhowells@redhat.com>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH 5/9] cr: capabilities: define checkpoint and restore fns
Date: Mon, 01 Jun 2009 12:34:13 -0400 [thread overview]
Message-ID: <4A240305.7030406@cs.columbia.edu> (raw)
In-Reply-To: <20090601154901.GA22301@us.ibm.com>
Serge E. Hallyn wrote:
> Quoting Andrew G. Morgan (morgan@kernel.org):
>> Serge,
>>
>> I'm not sure I'm too happy with hard coding the 64-bitness of
>> capability sets. It may well be a very long time before we increase
>> their size, but couldn't you prepare for that with some reference to
>> the prevailing magic numbers for the current ABI representation?
>
> Is the appended, updated version of the patch ok?
>
>> Also, the use of 'error' as both a variable and a goto destination
>> looks a little confusing.
>
> Ok, but that was in the original code. I can send a separate
> patch for mainline to change that, but it's not hurting
> anything at the moment so not sure it's worth it?
>
> -serge
>
> From aa72f022fb5788ab46658e6eb94eaf18e8c6568a Mon Sep 17 00:00:00 2001
> From: Serge E. Hallyn <serue@us.ibm.com>
> Date: Mon, 11 May 2009 09:44:42 -0400
> Subject: [PATCH 5/9] cr: capabilities: define checkpoint and restore fns
>
> An application checkpoint image will store capability sets
> (and the bounding set) as __u64s. Define checkpoint and
> restart functions to translate between those and kernel_cap_t's.
>
> Define a common function do_capset_tocred() which applies capability
> set changes to a passed-in struct cred.
>
> The restore function uses do_capset_tocred() to apply the restored
> capabilities to the struct cred being crafted, subject to the
> current task's (task executing sys_restart()) permissions.
>
> Changelog:
> Jun 01: Add commented BUILD_BUG_ON() to point out that the
> current implementation depends on 64-bit capabilities.
> (Andrew Morgan and Alexey Dobriyan).
> May 28: add helpers to c/r securebits
>
> Signed-off-by: Serge E. Hallyn <serue@us.ibm.com>
> ---
> include/linux/capability.h | 7 +++
> kernel/capability.c | 102 ++++++++++++++++++++++++++++++++++++++------
> security/commoncap.c | 51 +++++++++++++++-------
> 3 files changed, 130 insertions(+), 30 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index c302110..b3853ca 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -536,6 +536,13 @@ extern const kernel_cap_t __cap_empty_set;
> extern const kernel_cap_t __cap_full_set;
> extern const kernel_cap_t __cap_init_eff_set;
>
> +extern void checkpoint_save_cap(__u64 *dest, kernel_cap_t src);
> +struct cred;
> +extern int checkpoint_restore_cap(__u64 e, __u64 i, __u64 p, __u64 x,
> + struct cred *cred);
> +extern void checkpoint_save_securebits(unsigned *, unsigned);
> +extern int checkpoint_restore_securebits(unsigned, struct cred *);
(nit) How about:
checkpoint_capabilities() or checkpoint_cap_t()
restore_capabilities() or restore_cap_t()
? (also consistent with rest of the c/r code)
Oren.
next prev parent reply other threads:[~2009-06-01 16:34 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2009-05-29 22:32 [PATCH 0/9] credentials c/r: Introduction Serge E. Hallyn
2009-05-29 22:32 ` [PATCH 1/9] cred: #include init.h in cred.h Serge E. Hallyn
2009-05-29 22:32 ` [PATCH 2/9] groups: move code to kernel/groups.c Serge E. Hallyn
2009-05-29 22:33 ` [PATCH 3/9] cr: break out new_user_ns() Serge E. Hallyn
2009-05-29 22:33 ` [PATCH 4/9] cr: split core function out of some set*{u,g}id functions Serge E. Hallyn
2009-05-29 22:33 ` [PATCH 5/9] cr: capabilities: define checkpoint and restore fns Serge E. Hallyn
2009-05-31 20:26 ` Andrew G. Morgan
2009-05-31 20:56 ` Alexey Dobriyan
2009-06-01 1:38 ` Serge E. Hallyn
2009-06-01 2:18 ` Andrew G. Morgan
2009-06-01 13:35 ` Serge E. Hallyn
2009-06-01 15:46 ` Andrew G. Morgan
2009-06-01 22:18 ` Serge E. Hallyn
2009-06-02 13:49 ` Andrew G. Morgan
2009-06-02 14:23 ` Serge E. Hallyn
2009-06-02 15:26 ` Oren Laadan
2009-06-02 15:49 ` Andrew G. Morgan
2009-06-02 17:15 ` Serge E. Hallyn
2009-06-03 0:05 ` Oren Laadan
[not found] ` <4A25BE4F.6000603-eQaUEPhvms7ENvBUuze7eA@public.gmane.org>
2009-06-03 15:03 ` Andrew G. Morgan
2009-06-03 16:45 ` Serge E. Hallyn
2009-06-04 14:13 ` Andrew G. Morgan
2009-06-05 19:41 ` Serge E. Hallyn
2009-06-06 15:02 ` Andrew G. Morgan
2009-06-15 9:58 ` Alexey Dobriyan
2009-06-01 15:49 ` Serge E. Hallyn
2009-06-01 16:34 ` Oren Laadan [this message]
2009-05-29 22:33 ` [PATCH 6/9] cr: checkpoint and restore task credentials Serge E. Hallyn
[not found] ` <20090529223229.GA14536-r/Jw6+rmf7HQT0dZR+AlfA@public.gmane.org>
2009-05-29 22:33 ` [PATCH 7/9] cr: restore file->f_cred Serge E. Hallyn
2009-05-29 22:33 ` [PATCH 8/9] user namespaces: debug refcounts Serge E. Hallyn
2009-05-31 18:51 ` Alexey Dobriyan
2009-06-01 19:02 ` Serge E. Hallyn
2009-05-29 22:34 ` [PATCH 9/9] cr: ipc: reset kern_ipc_perms Serge E. Hallyn
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4A240305.7030406@cs.columbia.edu \
--to=orenl@cs.columbia.edu \
--cc=adobriyan@gmail.com \
--cc=containers@lists.osdl.org \
--cc=dhowells@redhat.com \
--cc=linux-security-module@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=serue@us.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.