All of lore.kernel.org
 help / color / mirror / Atom feed
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

  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.