From: Mingming Cao <cmm@us.ibm.com>
To: Eric Sandeen <sandeen@redhat.com>
Cc: Eric Paris <eparis@redhat.com>,
linux-ext4@vger.kernel.org, selinux@tycho.nsa.gov,
sds@tycho.nsa.gov, esandeen@redhat.com, tytso@mit.edu,
dwalsh@redhat.com, linux-security-module@vger.kernel.org
Subject: Re: ext4_has_free_blocks always checks cap_sys_resource and makes SELinux unhappy
Date: Fri, 24 Oct 2008 12:00:36 -0700 [thread overview]
Message-ID: <1224874836.6379.3.camel@mingming-laptop> (raw)
In-Reply-To: <4901FE29.3090600@redhat.com>
在 2008-10-24五的 11:56 -0500,Eric Sandeen写道:
> Eric Paris wrote:
> > I'm running an ext4 root filesystem and regularly get SELinux denials
> > like:
> >
> > Oct 16 08:32:55 localhost kernel: type=1400 audit(1224160369.076:5):
> > avc: denied { sys_resource } for pid=1624 comm="dbus-daemon"
> > capability=24 scontext=system_u:system_r:system_dbusd_t:s0
> > tcontext=system_u:system_r:system_dbusd_t:s0 tclass=capability
> >
> > https://bugzilla.redhat.com/show_bug.cgi?id=467216
> >
> > Since this doesn't happen with people who have ext3 filesystems but
> > everything else the same it lead me to look at ext4. I see that
> > ext?_has_free_blocks() has changed since ext3 and now we always check
> > for capable(CAP_SYS_RESOUCE). If a process actually has the capability
> > in pE (as many root processes would) but doesn't have the capability in
> > SELinux policy we will get a denial.
> >
> > I can think of a couple ways to fix this:
> >
> > the first (and one I like) is to change ext4 to stop checking
> > CAP_SYS_RESOURCE all the time. It's not really 'pretty' but I think you
> > would actually get a better performing function. Just always calculate
> > root_blocks and if we don't have enough room then then do the whole
> > check to see if are root and recalculate without root_blocks. I'd guess
> > that a great majority of the time operations will succeed even with a
> > non-zero root_blocks and I would guess that most process aren't going to
> > be root processes and so we would be calculating root_blocks anyway.
> > This would (like ext3) only cause these denials when it was filled up.
> > We've been living with that forever, so I don't see a problem there...
>
> Thanks Eric, I'll look into this. It seems that ext4_has_free_blocks is
> now overly complex; it used to return how many blocks are available, if
> that number is < nblocks, but the single caller now only checks
> success/failure for having nblocks free. I'll see if I can simplify it
> and delay the cap check as you suggest.
>
Most functionality in ext4_has_free_blocks() is duplicated in
ext4_claim_free_blocks(). I guess the ext4_has_free_blocks() could be
simplified a bit, or the two functional merge into one.
The delay cap check sounds right thing to me.
Mingming
> -Eric
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
next prev parent reply other threads:[~2008-10-24 19:00 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-24 15:05 ext4_has_free_blocks always checks cap_sys_resource and makes SELinux unhappy Eric Paris
2008-10-24 15:05 ` Eric Paris
2008-10-24 15:08 ` Stephen Smalley
2008-10-24 15:08 ` Stephen Smalley
2008-10-24 17:28 ` Eric Paris
2008-10-24 17:28 ` Eric Paris
2008-10-24 17:38 ` Stephen Smalley
2008-10-24 17:38 ` Stephen Smalley
2008-10-24 16:56 ` Eric Sandeen
2008-10-24 19:00 ` Mingming Cao [this message]
2008-10-24 19:02 ` Eric Sandeen
2008-10-27 1:39 ` Eric Sandeen
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=1224874836.6379.3.camel@mingming-laptop \
--to=cmm@us.ibm.com \
--cc=dwalsh@redhat.com \
--cc=eparis@redhat.com \
--cc=esandeen@redhat.com \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sandeen@redhat.com \
--cc=sds@tycho.nsa.gov \
--cc=selinux@tycho.nsa.gov \
--cc=tytso@mit.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 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.