From: "J. Bruce Fields" <bfields@fieldses.org>
To: Mimi Zohar <zohar@linux.vnet.ibm.com>
Cc: linux-kernel@vger.kernel.org,
linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, hch@infradead.org,
warthog9@kernel.org, david@fromorbit.com, jmorris@namei.org,
kyle@mcmartin.ca, hpa@zytor.com, akpm@linux-foundation.org,
torvalds@linux-foundation.org, mingo@elte.hu, eparis@redhat.com,
viro@zeniv.linux.org.uk, Matthew Wilcox <matthew@wil.cx>
Subject: Re: [PATCH 0/4] IMA: making i_readcount a first class inode citizen
Date: Fri, 5 Nov 2010 15:08:27 -0400 [thread overview]
Message-ID: <20101105190827.GC6492@fieldses.org> (raw)
In-Reply-To: <1288978685.3135.135.camel@localhost.localdomain>
On Fri, Nov 05, 2010 at 01:38:05PM -0400, Mimi Zohar wrote:
> 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.
Lease code could do that as well. (Probably just with a trylock,
failing the setlease if we can't get the lock.)
That misses rename, though, which doesn't take the i_mutex on the
renamed file. Which makes sense.
But a lease is used to give file server clients the right to do an open
locally, and we want them to be able to guarantee to applications that
the path (well, the last component, at least) still refers to the same
file at open time.
> > 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--
> >
> > ?
> >
>
> lol, getting i_readcount was was hard enough.
Argh. It really is a serious bug, for NFS at least. And I'm a little
out of non-inode-expanding ideas.
--b.
next prev parent reply other threads:[~2010-11-05 19:08 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-28 22:02 [PATCH 0/4] IMA: making i_readcount a first class inode citizen Mimi Zohar
2010-10-28 22:02 ` [PATCH 1/4] IMA: define readcount functions Mimi Zohar
2010-10-28 22:02 ` [PATCH 2/4] IMA: maintain i_readcount in the VFS layer Mimi Zohar
2010-10-29 14:13 ` Valdis.Kletnieks
2010-10-29 15:15 ` Valdis.Kletnieks
2010-10-28 22:02 ` [PATCH 3/4] IMA: remove IMA imbalance checking Mimi Zohar
2010-10-28 22:02 ` [PATCH 4/4] IMA: making i_readcount a first class inode citizen Mimi Zohar
2010-10-28 22:24 ` [PATCH 0/4] " Dave Chinner
2010-10-28 22:29 ` Linus Torvalds
2010-10-28 22:38 ` Mimi Zohar
2010-10-28 22:46 ` Linus Torvalds
2010-10-28 23:25 ` Al Viro
2010-10-28 22:45 ` Eric Paris
2010-10-29 0:30 ` Mimi Zohar
2010-11-06 10:44 ` Pavel Machek
2010-11-05 1:12 ` J. Bruce Fields
2010-11-05 11:08 ` Mimi Zohar
2010-11-05 16:28 ` J. Bruce Fields
2010-11-05 17:38 ` Mimi Zohar
2010-11-05 19:08 ` J. Bruce Fields [this message]
2010-11-05 20:58 ` J. Bruce Fields
2010-11-07 0:03 ` Mimi Zohar
-- strict thread matches above, loose matches on Subject: below --
2011-02-14 20:29 Mimi Zohar
2011-02-16 23:08 ` Mimi Zohar
2011-02-17 1:46 ` James Morris
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=20101105190827.GC6492@fieldses.org \
--to=bfields@fieldses.org \
--cc=akpm@linux-foundation.org \
--cc=david@fromorbit.com \
--cc=eparis@redhat.com \
--cc=hch@infradead.org \
--cc=hpa@zytor.com \
--cc=jmorris@namei.org \
--cc=kyle@mcmartin.ca \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-security-module@vger.kernel.org \
--cc=matthew@wil.cx \
--cc=mingo@elte.hu \
--cc=torvalds@linux-foundation.org \
--cc=viro@zeniv.linux.org.uk \
--cc=warthog9@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).