From: Eric Paris <eparis@redhat.com>
To: "Serge E. Hallyn" <serue@us.ibm.com>
Cc: James Morris <jmorris@namei.org>,
linux-kernel@vger.kernel.org, sds@tycho.nsa.gov,
morgan@kernel.org, selinux@tycho.nsa.gov
Subject: Re: [PATCH] capability: WARN when invalid capability is requested rather than BUG/panic
Date: Tue, 30 Sep 2008 13:22:30 -0400 [thread overview]
Message-ID: <1222795350.28251.98.camel@localhost.localdomain> (raw)
In-Reply-To: <20080930162830.GB31779@us.ibm.com>
On Tue, 2008-09-30 at 11:28 -0500, Serge E. Hallyn wrote:
> Quoting Eric Paris (eparis@redhat.com):
> > > Perhaps we should have CAP_TO_INDEX mask itself?
> > >
> > > #define CAP_TO_INDEX(x) (((x) >> 5) & _KERNEL_CAPABILITY_U32S)
> >
> > Well, you save a branch and won't get the pagefault so it does 'fix' the
> > pagefault/panic from cap code. It doesn't tell us when others screw up
> > and SELinux is still possibly going to BUG(). We are also going to
> > actually be returning a permission decision not on what was requested
> > but on something wholely different.
>
> So exactly what was requested?
A capability that they cannot possibly have since it doesn't exist :)
> > I like mine better, but I'm ok with yours and can just do my changes in
> > SELinux if this is how cap wants to handle it. I don't really like the
>
> Heh I don't like either one, just thought this would reduce the overhead
> a bit :)
No argument from me that patching up for buggy drivers sucks. Yours
would be less overhead, and it would return the cap system back to
pre-2.6.25 operation (garbage in garbage out but no panic). Since we
already have the branch in SELinux its no 'extra' overhead to EPERM
there instead of here (garbage in EPERM out).
-Eric
next prev parent reply other threads:[~2008-09-30 17:24 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-30 13:55 Eric Paris
2008-09-30 14:23 ` James Morris
2008-09-30 14:36 ` Eric Paris
2008-09-30 15:38 ` Serge E. Hallyn
2008-09-30 16:07 ` Eric Paris
2008-09-30 16:28 ` Serge E. Hallyn
2008-09-30 17:22 ` Eric Paris [this message]
2008-09-30 17:28 ` Arjan van de Ven
2008-10-01 15:32 ` Eric Paris
2008-10-01 15:39 ` Arjan van de Ven
2008-10-01 15:44 ` Serge E. Hallyn
2008-10-05 1:30 ` Andrew G. Morgan
[not found] <bhO5y-S0-29@gated-at.bofh.it>
[not found] ` <bhOyr-1kZ-5@gated-at.bofh.it>
[not found] ` <bhOyr-1kZ-3@gated-at.bofh.it>
[not found] ` <bhPuC-2yN-5@gated-at.bofh.it>
[not found] ` <bhPXy-3jl-13@gated-at.bofh.it>
[not found] ` <bhQh0-3CK-9@gated-at.bofh.it>
[not found] ` <bhRd4-4RS-9@gated-at.bofh.it>
[not found] ` <bhRd8-4RS-27@gated-at.bofh.it>
[not found] ` <bibY4-6WP-13@gated-at.bofh.it>
2008-10-01 19:36 ` Bodo Eggert
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=1222795350.28251.98.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=morgan@kernel.org \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
Powered by JetHome