linux-kernel - Re: [PATCH 0/5] fuse: close file synchronously

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20130415181739.GJ4068@ZenIV.linux.org.uk>
Date:	Mon, 15 Apr 2013 19:17:40 +0100
From:	Al Viro <viro@...IV.linux.org.uk>
To:	Miklos Szeredi <miklos@...redi.hu>
Cc:	Maxim Patlasov <mpatlasov@...allels.com>, dev@...allels.com,
	xemul@...allels.com, fuse-devel@...ts.sourceforge.net,
	bfoster@...hat.com, linux-kernel@...r.kernel.org, devel@...nvz.org,
	anand.avati@...il.com
Subject: Re: [PATCH 0/5] fuse: close file synchronously

On Mon, Apr 15, 2013 at 05:30:41PM +0200, Miklos Szeredi wrote:
> On Mon, Apr 15, 2013 at 5:08 PM, Miklos Szeredi <miklos@...redi.hu> wrote:
> > For example doing a readlink() on a magic symlink under /proc
> > shouldn't result in a synchronous call to a fuse filesystem.  Making
> > fput() synchronous may actually end up doing that (even if it's not
> > very likely).
> 
> Thinking about this a bit more.  As it is it sounds wrong to rely on a
> synchronous release, when in fact release is just not synchronous, as
> indicated by the above example.  Maybe it's the proc code that's buggy
> and shouldn't do get_file/fput because everyone is assuming release
> being synchronous with close().  Don't know.

What the hell?  ->release() is not and has never been synchronous with close().
There is any number of places where the final fput() might be called and no,
this readlink example is irrelevant - things like munmap()/dup2()/close
of a socket discarding a datagram with the last reference to struct file in
it, et sodding cetera.

Hell, another thread might be in the middle of read(2) at the moment when you
call close().  Result: the final fput() will be done when we are about to
return from that read(2).

People, ->release() is *NOT* guaranteed to be anywhere near close(2).  Never
had been.
--
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/