linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-security-module@vger.kernel.org, linux-fsdevel@vger.kernel.org
Subject: Re: [RFC][PATCH] ima: fix lockdep circular locking dependency
Date: Wed, 16 Nov 2011 15:49:02 -0500	[thread overview]
Message-ID: <1321476542.10093.98.camel@localhost> (raw)
In-Reply-To: <1321475044.1931.29.camel@falcor>

On Wed, 2011-11-16 at 15:24 -0500, Mimi Zohar wrote:
> On Wed, 2011-11-16 at 12:27 -0500, Eric Paris wrote:

> > > +int ima_file_premmap(struct file *file, unsigned long prot)
> > > +{
> > > +	int rc;
> > > +
> > > +	if (!file)
> > > +		return 0;
> > > +	if (prot & PROT_EXEC)
> > > +		rc = process_measurement(file, file->f_dentry->d_name.name,
> > > +					 MAY_EXEC, FILE_PREMMAP);
> > > +	return 0;
> > > +}
> > 
> > Here lets call the helper above, but instead of FILE_PREMMAP, lets use
> > the correct FILE_MMAP or FILE_BPRM, which is going to have to come as a
> > third argument, right?
> 
> Ok, thanks for the review.

Actually it just dawned on me, that what I think we really learned here
is that we have the hooks in the wrong place.  If we are going to
sprinkle the code with ima_file_premmap() maybe we should just actually
do ALL of the work in this new hook?  Throw the security_file_mmap() IMA
hook out the window and just actually do the whole process_measurement()
work in this new hook?    You'll have to see if that's better.  But it
sucks to allocate an object just to have to look it up 100 instructions
later.  Why not just do the work when we do the allocation and not come
back a second time?

-Eric


  reply	other threads:[~2011-11-16 20:49 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-11-15 12:31 [RFC][PATCH] ima: fix lockdep circular locking dependency Mimi Zohar
2011-11-15 14:17 ` Kasatkin, Dmitry
2011-11-15 14:44   ` Mimi Zohar
2011-11-15 17:05     ` Kasatkin, Dmitry
2011-11-15 23:04       ` Mimi Zohar
2011-11-16  9:35         ` Kasatkin, Dmitry
2011-11-16 13:52           ` Mimi Zohar
2011-11-16 17:27 ` Eric Paris
2011-11-16 20:24   ` Mimi Zohar
2011-11-16 20:49     ` Eric Paris [this message]
2011-11-16 21:05       ` 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=1321476542.10093.98.camel@localhost \
    --to=eparis@redhat.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=zohar@linux.vnet.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;
as well as URLs for NNTP newsgroup(s).