linux-kernel - Re: v9fs does not honor open file handles on anonymous files

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: <20131231194110.GA28209@nautica>
Date:	Tue, 31 Dec 2013 20:41:11 +0100
From:	Dominique Martinet <dominique.martinet@....fr>
To:	Richard Yao <ryao@...too.org>
Cc:	Kernel development list <linux-kernel@...r.kernel.org>,
	linux-fsdevel@...r.kernel.org,
	"v9fs-developer@...ts.sourceforge.net" 
	<v9fs-developer@...ts.sourceforge.net>,
	"kernel@...too.org" <kernel@...too.org>,
	Eric Van Hensbergen <ericvh@...il.com>,
	Ron Minnich <rminnich@...dia.gov>,
	Latchesar Ionkov <lucho@...kov.net>,
	"Aneesh Kumar K.V" <aneesh.kumar@...ux.vnet.ibm.com>
Subject: Re: v9fs does not honor open file handles on anonymous files

Hi,

Richard Yao wrote on Tue, Dec 31, 2013 :
> #!/bin/bash
> cat <<-EOF
> EOF
> 
> Running this causes bash to fork via clone(), set fd=0 to point to an
> empty file in /tmp, unlink it and then execve cat. Specifically,
> something like this;
> 
> [pid  3699] open("/tmp/sh-thd-1388524249",
> O_WRONLY|O_CREAT|O_EXCL|O_TRUNC, 0600) = 3
> [pid  3699] open("/tmp/sh-thd-1388524249", O_RDONLY) = 4
> [pid  3699] close(3)                    = 0
> [pid  3699] unlink("/tmp/sh-thd-1388524249") = 0
> [pid  3699] dup2(4, 0)                  = 0
> [pid  3699] close(4)                    = 0
> [pid  3699] execve("/bin/cat", ["cat"], [/* 22 vars */]) = 0
> 
> It seems that v9fs_vfs_unlink() is killing the file while we still have
> open file handles. I have confirmed that this behavior occurs on Linux
> 3.13.0-rc6. This breaks several things when Gentoo is on a 9p rootfs
> (e.g. gcc-config, any emerge command that involves a C compiler,
> etcetera) inside QEMU. I have placed /tmp and /var/tmp/portage on a
> tmpfs as a hack-fix, but it would be better to get this fixed.
> 
> I doubt that I will write a patch to fix this. I am sending the details
> to the list so the 9p maintainers or any other interested individual can
> fix it.

I'm not sure if it is the client's job to remember the file has been
unlinked and only really unlink it after all the file handles are closed
or if we should expect the server to do it.

It might not matter in the case of qemu acting as a 9p server, but there
are a couple of network 9p2000.L servers out there (diod[1] and
nfs-ganesha[2]), and if the file is open on one client and unlinked on
another client.. How can the second client wait properly?

For what's it's worth, nfs-ganesha already behaves properly and this
will work with /tmp being a 9P mount off it.


It might be worth looking into qemu's code and see if it wouldn't be
easy to hold the unlink ? I've got to admit I honestly have no clue
there.
(or at least send them a copy of your mail :))


[1] diod "Distributed I/O daemon" - http://code.google.com/p/diod/
[2] nfs-ganesha - https://github.com/nfs-ganesha/nfs-ganesha


Cheers,
-- 
Dominique Martinet
--
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/