From: "Michael Glasgow" <glasgowNOSPAM@beer.net>
To: "Andy Lutomirski" <luto@stanford.edu>, <linux-kernel@vger.kernel.org>
Subject: Re: posix capabilities inheritance
Date: Wed, 22 Oct 2003 02:11:20 -0500 (CDT) [thread overview]
Message-ID: <200310220711.h9M7BKAf099719@dark.beer.net> (raw)
In-Reply-To: <fa.f36f4t9.1rg8j3v@ifi.uio.no>
Andy Lutomirski wrote:
> 1. Can a process have capabilities in its inheritable set and not
> in its permitted set? POSIX allows such processes to be created
> (pI = pP = full, then execute (fI = 0, fP = 0).
Sure, this is apparent to me in reading the spec. I'm not exactly
sure if this is relavent though: if pP = pE = 0, it does not seem
like it should be possible for pI=full to have any effect on exec,
unless I am missing something.
> Nevertheless, its pP evolution rule assumes that this never happens
> (pI capabilities can reappear).
Certainly with the current rule as implemented in 2.4, it looks as
though you can regain permitted flags: pP' = (fP & X) | (fI & pI)
Is this what you mean when you say they can reappear? WRT the
spec itself, I don't see this assumption. The rule could just as
easily be: pP' = (fP & X) | (pP & fI & pI) (just an example)
The rule in your patch seems like it should be compliant as well.
I'm not saying there aren't some problems to be worked out with
the spec; I think there are. But I don't think this is a case of
the spec being broken per se -- just too vague.
> 2. If a process has pE < pP (i.e. some caps disabled, e.g. uid=0,
> euid!=0), and exec's fE=full, then its capabilities get re-enabled.
> This seems like a pretty serious breakage of userspace.
How is this any different from traditional *nix setuid semantics?
I suppose I can see your point somewhat if you are concerned
specifically about the case where pE < pP execs fE=full && fP=0,
but I am unconvinced this constitutes serious breakage. On the
contrary, I think it seems most reasonable for those caps to be
reenabled, especially for caps where fI=1, but perhaps even when
fI=0.
I'm still looking over your patches to try to figure out how exactly
you think this stuff should work. I'm glad to see someone out
there is thinking about this. You're right, it's pretty complex
and still far from useable.
--
Michael Glasgow < glasgow at beer dot net >
next parent reply other threads:[~2003-10-22 7:11 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <fa.f36f4t9.1rg8j3v@ifi.uio.no>
2003-10-22 7:11 ` Michael Glasgow [this message]
2003-10-22 19:40 ` Andy Lutomirski
[not found] <fa.f26d55g.1qgijbi@ifi.uio.no>
[not found] ` <fa.hq0dft9.9i0obd@ifi.uio.no>
2003-10-24 21:24 ` Andy Lutomirski
[not found] <fa.n4rmmgg.2423pm@ifi.uio.no>
[not found] ` <fa.l1oevhb.1s5k583@ifi.uio.no>
2003-10-24 8:44 ` Andy Lutomirski
2003-10-24 12:41 ` Theodore Ts'o
2003-10-24 16:44 ` Andy Lutomirski
2003-10-24 20:58 ` David Wagner
[not found] <fa.f4bs2b4.fhub0m@ifi.uio.no>
2003-10-23 22:05 ` Michael Glasgow
2003-10-23 22:59 ` Theodore Ts'o
2003-10-24 1:36 ` Ernie Petrides
2003-10-24 2:19 ` Bernd Eckenfels
2003-10-24 5:10 ` Ernie Petrides
2003-10-25 19:51 ` Pavel Machek
2003-10-23 1:41 Albert Cahalan
[not found] <fa.f9mv0tb.27sf3j@ifi.uio.no>
2003-10-23 1:36 ` Michael Glasgow
2003-10-23 1:57 ` Andy Lutomirski
[not found] <fa.hehull9.10mmngt@ifi.uio.no>
2003-10-21 18:24 ` Andy Lutomirski
-- strict thread matches above, loose matches on Subject: below --
2003-10-21 11:26 Michael Glasgow
2003-10-23 16:46 ` Theodore Ts'o
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=200310220711.h9M7BKAf099719@dark.beer.net \
--to=glasgownospam@beer.net \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@stanford.edu \
/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
all inboxes | Powered by JetHome®