From: Al Viro <viro@ZenIV.linux.org.uk>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org, Eric Paris <eparis@redhat.com>,
Hugh Dickins <hugh.dickins@tiscali.co.uk>,
James Morris <jmorris@namei.org>,
David Safford <safford@watson.ibm.com>,
"Serge E. Hallyn" <serue@linux.vnet.ibm.com>,
Mimi Zohar <zohar@us.ibm.com>
Subject: Re: [RFC PATCH 1/2] Fix 1 untangling ima mess, part 2 with counters
Date: Mon, 25 Jan 2010 21:30:42 +0000 [thread overview]
Message-ID: <20100125213042.GZ19799@ZenIV.linux.org.uk> (raw)
In-Reply-To: <1264447477.3696.30.camel@dyn9002018117.watson.ibm.com>
On Mon, Jan 25, 2010 at 02:24:37PM -0500, Mimi Zohar wrote:
> The IMA counters are updated in alloc_file() and __dentry_open().
> __dentry_open() is called from a couple of places:
> lookup_instantiate_filp(), nameidata_to_filp() and dentry_open. Of
> these calls, files are only being measured in the nameidata_to_filp()
> path. So yes, the current ima_path_check() needs to be moved to after
> the dentry_open() in nfsd_open(), and also added after each of the other
> dentry_open() and lookup_instantiate_filp() calls. Otherwise the
> counters will be correct, but the files will not be measured.
Wrong. lookup_instantiate_filp() is followed by do_filp_open() ones.
So no, we don't need to add there. As for other dentry_open(), I'm
not at all convinced that we *want* ima_path_check() done for all
of those; it should be decided on per-call basis and it's not a trivial
decision.
next prev parent reply other threads:[~2010-01-25 21:30 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-01-20 20:35 [RFC PATCH 0/2] Fix untangling ima mess, part 2 with counters Mimi Zohar
2010-01-20 20:35 ` [RFC PATCH 1/2] Fix 1 " Mimi Zohar
2010-01-23 23:07 ` Al Viro
2010-01-25 19:24 ` Mimi Zohar
2010-01-25 21:30 ` Al Viro [this message]
2010-01-26 13:03 ` Al Viro
2010-01-26 15:16 ` Mimi Zohar
2010-01-26 16:27 ` Al Viro
[not found] ` <1264520125.3789.32.camel@dyn9002018117.watson.ibm.com>
[not found] ` <20100126163143.GJ19799@ZenIV.linux.org.uk>
[not found] ` <1264528747.3062.11.camel@dyn9002018117.watson.ibm.com>
2010-01-26 19:41 ` Open Intents, lookup_instantiate_filp() And All That Shit(tm) Al Viro
2010-01-26 22:01 ` [RFC PATCH 1/2] Fix 1 untangling ima mess, part 2 with counters Mimi Zohar
2010-01-20 20:35 ` [RFC PATCH 2/2] Fix 2 " Mimi Zohar
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=20100125213042.GZ19799@ZenIV.linux.org.uk \
--to=viro@zeniv.linux.org.uk \
--cc=eparis@redhat.com \
--cc=hugh.dickins@tiscali.co.uk \
--cc=jmorris@namei.org \
--cc=linux-kernel@vger.kernel.org \
--cc=safford@watson.ibm.com \
--cc=serue@linux.vnet.ibm.com \
--cc=zohar@linux.vnet.ibm.com \
--cc=zohar@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 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.