public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <dan@debian.org>
To: linux-kernel@vger.kernel.org
Subject: Re: Capabilities-related change in 2.5.40
Date: Tue, 1 Oct 2002 17:12:11 -0400	[thread overview]
Message-ID: <20021001211210.GA8784@nevyn.them.org> (raw)
In-Reply-To: <20021001134552.A26557@figure1.int.wirex.com>

On Tue, Oct 01, 2002 at 01:45:52PM -0700, Chris Wright wrote:
> > Second of all, my login shell (as a user) gets a very bizarre response to sys_capget:
> > 
> > capget(0x19980330, 0, {CAP_CHOWN | CAP_DAC_OVERRIDE | CAP_DAC_READ_SEARCH |
> >   CAP_FOWNER | CAP_FSETID | CAP_KILL | CAP_SETGID | CAP_SETUID |
> >   CAP_LINUX_IMMUTABLE | CAP_NET_BIND_SERVICE | CAP_NET_BROADCAST |
> >   CAP_NET_ADMIN | CAP_NET_RAW | CAP_IPC_LOCK | CAP_IPC_OWNER | CAP_SYS_MODULE
> >   | CAP_SYS_RAWIO | CAP_SYS_CHROOT | CAP_SYS_PTRACE | CAP_SYS_PACCT |
> >   CAP_SYS_ADMIN | CAP_SYS_BOOT | CAP_SYS_NICE | CAP_SYS_RESOURCE |
> >   CAP_SYS_TIME | CAP_SYS_TTY_CONFIG | 0xf8000000,
> >   CAP_CHOWN | CAP_DAC_OVERRIDE
> >   | CAP_DAC_READ_SEARCH | CAP_FOWNER | CAP_FSETID | CAP_KILL | CAP_SETGID |
> >   CAP_SETUID | CAP_SETPCAP | CAP_LINUX_IMMUTABLE | CAP_NET_BIND_SERVICE |
> >   CAP_NET_BROADCAST | CAP_NET_ADMIN | CAP_NET_RAW | CAP_IPC_LOCK |
> >   CAP_IPC_OWNER | CAP_SYS_MODULE | CAP_SYS_RAWIO | CAP_SYS_CHROOT |
> >   CAP_SYS_PTRACE | CAP_SYS_PACCT | CAP_SYS_ADMIN | CAP_SYS_BOOT | CAP_SYS_NICE
> >   | CAP_SYS_RESOURCE | CAP_SYS_TIME | CAP_SYS_TTY_CONFIG | 0xf8000000,}) = 0
> > 
> > The reason?  cap_get_proc has always been broken.  But the capability set of
> > task 0, swapper, has now changed.  It used to be empty.  So, I'll go report
> > this to libcap.  The change in capabilities for swapper is presumably
> > benign.
> 
> I'm not sure what you are pointing out?  Is cap_get_proc using header.pid = 0
> regardless?  Hmm, yes.
> 
> cap_get_proc()
> 	cap_init()
> 		malloc
> 		memset(0)
> 		head.version = _LINUX_CAPABILITY_VERSION
> 	capget(&head, &set)	<-- head.pid = 0
> 

Yes.  It was pointed out to me that libcap2 snapshots behave correctly.

> Also, I've just looked at 2.2, 2.4, 2.5 and they all have the same caps
> for INIT_TASK:
> 
> 2.2
> #define CAP_FULL_SET        to_cap_t(~0)
> #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
> #define CAP_INIT_INH_SET    to_cap_t(0)
> /* caps */	CAP_INIT_EFF_SET,CAP_INIT_INH_SET,CAP_FULL_SET,	\
> /* keep_caps */	0,  						\
> 
> 2.4
> #define CAP_FULL_SET        to_cap_t(~0)
> #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
> #define CAP_INIT_INH_SET    to_cap_t(0)
>     cap_effective:	CAP_INIT_EFF_SET,	\
>     cap_inheritable:	CAP_INIT_INH_SET,	\
>     cap_permitted:	CAP_FULL_SET,		\
>     keep_capabilities:	0,			\
> 
> 2.5
> #define CAP_FULL_SET        to_cap_t(~0)
> #define CAP_INIT_EFF_SET    to_cap_t(~0 & ~CAP_TO_MASK(CAP_SETPCAP))
> #define CAP_INIT_INH_SET    to_cap_t(0)
> 	.cap_effective  = CAP_INIT_EFF_SET,	\
> 	.cap_inheritable = CAP_INIT_INH_SET,	\
> 	.cap_permitted  = CAP_FULL_SET,		\
> 	.keep_capabilities = 0,			\

Not init: swapper.  Try it on 2.4:
drow@nevyn:~% getpcaps 0
Capabilities for `0': =

2.5.40 gives me a very different answer :)

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

  reply	other threads:[~2002-10-01 21:06 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-10-01 16:49 Capabilities-related change in 2.5.40 Daniel Jacobowitz
2002-10-01 20:45 ` Chris Wright
2002-10-01 21:12   ` Daniel Jacobowitz [this message]
2002-10-02  7:38     ` [PATCH] " Chris Wright
2002-10-02 13:23       ` Daniel Jacobowitz
2002-10-02 14:33         ` Robert Love
2002-10-02 16:44           ` Chris Wright
2002-10-02 18:10             ` Robert Love
2002-10-02 18:21               ` Chris Wright
2002-10-02 16:25         ` Chris Wright

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=20021001211210.GA8784@nevyn.them.org \
    --to=dan@debian.org \
    --cc=linux-kernel@vger.kernel.org \
    /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