[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <1288978685.3135.135.camel@localhost.localdomain>
Date: Fri, 05 Nov 2010 13:38:05 -0400
From: Mimi Zohar <zohar@...ux.vnet.ibm.com>
To: "J. Bruce Fields" <bfields@...ldses.org>
Cc: linux-kernel@...r.kernel.org,
linux-security-module@...r.kernel.org,
linux-fsdevel@...r.kernel.org, hch@...radead.org,
warthog9@...nel.org, david@...morbit.com, jmorris@...ei.org,
kyle@...artin.ca, hpa@...or.com, akpm@...ux-foundation.org,
torvalds@...ux-foundation.org, mingo@...e.hu, eparis@...hat.com,
viro@...iv.linux.org.uk, Matthew Wilcox <matthew@....cx>
Subject: Re: [PATCH 0/4] IMA: making i_readcount a first class inode citizen
On Fri, 2010-11-05 at 12:28 -0400, J. Bruce Fields wrote:
> On Fri, Nov 05, 2010 at 07:08:06AM -0400, Mimi Zohar wrote:
> > Right, like the ima_file_check(), which is after the __dentry_open().
> > Al, is it possible to move the break_lease() in may_open() to later?
>
> That would still leave a race like:
>
> check count
> bump count
> break lease
> set lease
>
> But we could extend the i_lock to prevent the lease being bumped between
> the two steps on the right-hand side.
The latest i_readcount patchset, i_readcount is atomic and doesn't
require i_lock, at least for IMA. Have to think about this more ....
> At that point I think we'd be done? We're assured the count is still
> zero while the lease is added to the inode, so anyone in the process of
> doing an open has yet to reach the break_lease, which will see the newly
> added lease.
>
> That leaves the problem that leases really should be broken on anything
> that changes the attributes or the dentries pointing to the inode:
> setattr, link, unlink, rename, at least.
For this reason, IMA is now taking i_mutex, preventing file metadata
from changing.
> One approach: add another counter to the inode named disable_leases, and
> have any of those operations do something like:
>
> disable_lease++
> break_lease
> ... do operation ...
> disable_lease--
>
> ?
>
> --b.
lol, getting i_readcount was was hard enough.
Mimi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists