From: Mimi Zohar <zohar@linux.vnet.ibm.com>
To: sekharan@us.ibm.com
Cc: Christoph Hellwig <hch@infradead.org>,
Eric Paris <eparis@parisplace.org>,
linux-security-module@vger.kernel.org,
sekharan@linux.vnet.ibm.com, XFS Mailing List <xfs@oss.sgi.com>
Subject: Re: [PATCH] security: Delay freeing inode->i_security till the end of RCU grace period
Date: Tue, 06 Dec 2011 14:45:53 -0500 [thread overview]
Message-ID: <1323200753.2165.69.camel@falcor> (raw)
In-Reply-To: <1323191093.31919.1475.camel@chandra-lucid.austin.ibm.com>
On Tue, 2011-12-06 at 11:04 -0600, Chandra Seetharaman wrote:
> On Tue, 2011-12-06 at 11:30 -0500, Mimi Zohar wrote:
> > On Tue, 2011-12-06 at 10:14 -0500, Christoph Hellwig wrote:
> > > On Mon, Dec 05, 2011 at 12:42:21PM -0600, Chandra Seetharaman wrote:
> > > > while running test case 234 from xfstests test suite, I was getting an
> > > > occational memory fault in inode_has_perm() with the following stack
> > >
> > > Interesting. Given that have no good way to free other data with the
> > > normal inode callback it looks like we indeed need to do this
> > > separately.
> > >
> > > What about IMA or similar monsters? Posix ACLs already are covered at
> > > least.
> >
> > Looks like a similar problem exists with the 'iint'.
>
> I walked thru the code and saw integrity_iint_find() is the one that
> would be used to see if a iint data structure is associated. And, all
> all the invocations of integrity_iint_find() check for NULL and handle
> it properly.
>
> I might be wrong since I am not familiar with the code. Can you please
> double check and let me know if I am wrong.
>
> Chandra
The assumption up to this point has been that the iint will be freed
only after the last call to ima_file_free(). The lack of an iint's
existence indicates that the file is not in the measurement policy.
As the iint is being freed, updating the iint flag is unnecessary for
base IMA. However, in addition to updating the iint flags, the
IMA-appraisal patches (yet to be upstreamed) update the 'security.ima'
xattr. Without an iint, the xattr will not be updated.
Mimi
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
next prev parent reply other threads:[~2011-12-06 19:50 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-12-05 18:42 [PATCH] security: Delay freeing inode->i_security till the end of RCU grace period Chandra Seetharaman
2011-12-06 15:14 ` Christoph Hellwig
2011-12-06 16:09 ` Chandra Seetharaman
2011-12-06 16:44 ` Mimi Zohar
2011-12-06 16:30 ` Mimi Zohar
2011-12-06 17:04 ` Chandra Seetharaman
2011-12-06 19:45 ` Mimi Zohar [this message]
2011-12-06 22:28 ` Chandra Seetharaman
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=1323200753.2165.69.camel@falcor \
--to=zohar@linux.vnet.ibm.com \
--cc=eparis@parisplace.org \
--cc=hch@infradead.org \
--cc=linux-security-module@vger.kernel.org \
--cc=sekharan@linux.vnet.ibm.com \
--cc=sekharan@us.ibm.com \
--cc=xfs@oss.sgi.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