From: "Serge E. Hallyn" <serge@hallyn.com>
To: Andrew Vagin <avagin@openvz.org>
Cc: linux-kernel@vger.kernel.org, criu@openvz.org,
Pavel Emelyanov <xemul@parallels.com>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Serge Hallyn <serge.hallyn@canonical.com>,
linux-security-module@vger.kernel.org
Subject: Re: [PATCH] proc: don't show nonexistent capabilities
Date: Wed, 3 Oct 2012 16:24:12 +0000 [thread overview]
Message-ID: <20121003162410.GA6692@mail.hallyn.com> (raw)
In-Reply-To: <1349209832-279922-1-git-send-email-avagin@openvz.org>
Quoting Andrew Vagin (avagin@openvz.org):
> Without this patch it is really hard to interpret a bounding set,
> if CAP_LAST_CAP is unknown for a current kernel.
>
> Non-existant capabilities can not be deleted from a bounding set
> with help of prctl.
>
> E.g.: Here are two examples without/with this patch.
> CapBnd: ffffffe0fdecffff
> CapBnd: 00000000fdecffff
>
> I suggest to hide non-existent capabilities. Here is two reasons.
> * It's logically and easier for using.
> * It helps to checkpoint-restore capabilities of tasks, because tasks
> can be restored on another kernel, where CAP_LAST_CAP is bigger.
>
> Cc: Serge Hallyn <serge.hallyn@canonical.com>
Hm, I don't object to this patch. Sounds useful indeed. I can't
help shake the feeling though that something somewhere will get
confused by this (though it shouldn't), so I'd like to do some
testing. Have you run ltp against this? Are you running this
daily with your distro?
> Cc: Pavel Emelyanov <xemul@parallels.com>
> Signed-off-by: Andrew Vagin <avagin@openvz.org>
> ---
> include/linux/capability.h | 3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/include/linux/capability.h b/include/linux/capability.h
> index d10b7ed..1642778 100644
> --- a/include/linux/capability.h
> +++ b/include/linux/capability.h
> @@ -420,7 +420,8 @@ extern const kernel_cap_t __cap_init_eff_set;
> #else /* HAND-CODED capability initializers */
>
> # define CAP_EMPTY_SET ((kernel_cap_t){{ 0, 0 }})
> -# define CAP_FULL_SET ((kernel_cap_t){{ ~0, ~0 }})
> +# define CAP_FULL_SET ((kernel_cap_t){{ ~0, \
> + CAP_TO_MASK(CAP_LAST_CAP + 1) - 1 } })
> # define CAP_FS_SET ((kernel_cap_t){{ CAP_FS_MASK_B0 \
> | CAP_TO_MASK(CAP_LINUX_IMMUTABLE), \
> CAP_FS_MASK_B1 } })
> --
> 1.7.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
next prev parent reply other threads:[~2012-10-03 16:22 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-10-02 20:30 [PATCH] proc: don't show nonexistent capabilities Andrew Vagin
2012-10-03 16:24 ` Serge E. Hallyn [this message]
2012-10-04 21:42 ` Andrey Wagin
2012-10-05 14:05 ` Serge E. Hallyn
2012-10-05 15:54 ` Andrew G. Morgan
2012-10-05 16:46 ` Serge 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=20121003162410.GA6692@mail.hallyn.com \
--to=serge@hallyn.com \
--cc=avagin@openvz.org \
--cc=criu@openvz.org \
--cc=gorcunov@openvz.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=serge.hallyn@canonical.com \
--cc=xemul@parallels.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox