From: Eric Paris <eparis@redhat.com>
To: Artem Bityutskiy <dedekind@yandex.ru>
Cc: linux-kernel@vger.kernel.org, sct@redhat.com,
akpm@linux-foundation.org, adilger@sun.com, tytso@mit.edu,
linux-ext4@vger.kernel.org, dedekind@infradead.org,
ext-adrian.hunter@nokia.com, linux-mtd@lists.infradead.org,
dushistov@mail.ru, jmorris@namei.org
Subject: Re: [PATCH] filesystems: use has_capability_noaudit interface for reserved blocks checks
Date: Fri, 14 Nov 2008 10:36:01 -0500 [thread overview]
Message-ID: <1226676961.3353.78.camel@localhost.localdomain> (raw)
In-Reply-To: <491D2F09.3070104@yandex.ru>
On Fri, 2008-11-14 at 09:55 +0200, Artem Bityutskiy wrote:
> Eric Paris wrote:
> > ext[2,3,4], ufs, and ubifs all check for CAP_SYS_RESOURCE to determine
> > if they should allow reserved blocks to be used. A process not having
> > this capability is not failing some security decision and should not be
> > audited. Thus move to using has_capability_noaudit.
> >
> > Signed-off-by: Eric Paris <eparis@redhat.com>
> > ---
>
> UBIFS part looks OK, as long as the whole idea of the patch is right, which
> I have not checked, but assume it is.
>
> The only question is are you sure exporting 'cap_capable()' is relevant
> to this patch? You do not seem to call it directly.
After this change, modules call has_capability_noaudit() which is a
#define which turns this into modules calling
security_capable_noaudit(). You noticed this and decided it was correct
to make that export. But when CONFIG_SECURITY is not set
security_capable_notaudit() is a static inline which calls
cap_capable(). See include/linux/security.h line 2832 in the linux-next
tree. Now modules are calling cap_capable directly, thus the export.
-Eric
WARNING: multiple messages have this Message-ID (diff)
From: Eric Paris <eparis@redhat.com>
To: Artem Bityutskiy <dedekind@yandex.ru>
Cc: adilger@sun.com, tytso@mit.edu, ext-adrian.hunter@nokia.com,
sct@redhat.com, linux-kernel@vger.kernel.org, jmorris@namei.org,
linux-mtd@lists.infradead.org, dushistov@mail.ru,
akpm@linux-foundation.org, linux-ext4@vger.kernel.org
Subject: Re: [PATCH] filesystems: use has_capability_noaudit interface for reserved blocks checks
Date: Fri, 14 Nov 2008 10:36:01 -0500 [thread overview]
Message-ID: <1226676961.3353.78.camel@localhost.localdomain> (raw)
In-Reply-To: <491D2F09.3070104@yandex.ru>
On Fri, 2008-11-14 at 09:55 +0200, Artem Bityutskiy wrote:
> Eric Paris wrote:
> > ext[2,3,4], ufs, and ubifs all check for CAP_SYS_RESOURCE to determine
> > if they should allow reserved blocks to be used. A process not having
> > this capability is not failing some security decision and should not be
> > audited. Thus move to using has_capability_noaudit.
> >
> > Signed-off-by: Eric Paris <eparis@redhat.com>
> > ---
>
> UBIFS part looks OK, as long as the whole idea of the patch is right, which
> I have not checked, but assume it is.
>
> The only question is are you sure exporting 'cap_capable()' is relevant
> to this patch? You do not seem to call it directly.
After this change, modules call has_capability_noaudit() which is a
#define which turns this into modules calling
security_capable_noaudit(). You noticed this and decided it was correct
to make that export. But when CONFIG_SECURITY is not set
security_capable_notaudit() is a static inline which calls
cap_capable(). See include/linux/security.h line 2832 in the linux-next
tree. Now modules are calling cap_capable directly, thus the export.
-Eric
next prev parent reply other threads:[~2008-11-14 15:37 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-11 19:12 [PATCH] filesystems: use has_capability_noaudit interface for reserved blocks checks Eric Paris
2008-11-11 19:12 ` Eric Paris
2008-11-13 0:19 ` Mingming Cao
2008-11-13 0:19 ` Mingming Cao
2008-11-13 0:19 ` Mingming Cao
2008-11-13 22:53 ` Andrew Morton
2008-11-13 22:53 ` Andrew Morton
2008-11-13 23:07 ` Theodore Tso
2008-11-13 23:07 ` Theodore Tso
2008-11-14 7:55 ` Artem Bityutskiy
2008-11-14 7:55 ` Artem Bityutskiy
2008-11-14 7:55 ` Artem Bityutskiy
2008-11-14 15:36 ` Eric Paris [this message]
2008-11-14 15:36 ` Eric Paris
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=1226676961.3353.78.camel@localhost.localdomain \
--to=eparis@redhat.com \
--cc=adilger@sun.com \
--cc=akpm@linux-foundation.org \
--cc=dedekind@infradead.org \
--cc=dedekind@yandex.ru \
--cc=dushistov@mail.ru \
--cc=ext-adrian.hunter@nokia.com \
--cc=jmorris@namei.org \
--cc=linux-ext4@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mtd@lists.infradead.org \
--cc=sct@redhat.com \
--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.