linux-kernel - [PATCH 0/3] fs/9p: fix setattr/getattr issues with open 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-next>] [day] [month] [year] [list]

Message-Id: <146659832556.15781.17414806975641516683.stgit@bahia.lan>
Date:	Wed, 22 Jun 2016 14:25:25 +0200
From:	Greg Kurz <groug@...d.org>
To:	Eric Van Hensbergen <ericvh@...il.com>
Cc:	Latchesar Ionkov <lucho@...kov.net>,
	Dominique Martinet <dominique.martinet@....fr>,
	linux-kernel@...r.kernel.org, qemu-devel@...gnu.org,
	v9fs-developer@...ts.sourceforge.net,
	Ron Minnich <rminnich@...dia.gov>,
	"David S. Miller" <davem@...emloft.net>
Subject: [PATCH 0/3] fs/9p: fix setattr/getattr issues with open files

The 9p filesystem has some serious issues with all syscalls that deal
with file attributes out of a file descriptor instead of a path name
(aka. fstat, ftruncate, fchmod and friends). If the file is opened and
then unlinked, any subsequent call to the above syscalls will fail with
EACCES. The same will happen to ftruncate() if the file is no longer
writable.

The root cause to this is that the VFS layer does not pass the struct
file to the filesystem when it is about file attributes. This is
legitimate: when we reach setattr/getattr, we don't need anything to
be dereferenced from the struct file. But the current lookup code is
based on the list of fids hanging off the dentry: it is okay for path
name based syscalls, but not relialable in the case of file descriptors
because we cannot find an open fid this way.

Eric sent a patch last year to address the case when the file gets
unlinked:

https://patchwork.kernel.org/patch/6252761/

The general idea is to try to find an open fid, starting from the inode.
The patch does this by browsing the 9p client list of all fids when we
know the file was unlinked: if we find a fid, it is necessarily an open
fid.

I could find a newer version of this patch with some minor changes, here:

https://github.com/ericvh/linux/commits/v9fs-devel

Since the patch also fixes a few other things, I re-post it first in
this series. Eric, I hope it is okay for you ?

As suggested in the changelog, the lookup of open fid can be optimized
if we link open fids to the inode. This is addressed by the second patch.

The third patch addresses a related issue with ftruncate() on unwriteable
files.

This series can be tested with a custom QEMU, available here:

https://github.com/gkurz/qemu/commits/9p-attr-fixes

I could have most f*() syscalls working in the guest, with the notable
exception of xattr related ones because more code is needed in QEMU.

Please comment. Test reports will also be appreciated :)

---

Eric Van Hensbergen (1):
      fs/9p: fix create-unlink-getattr idiom

Greg Kurz (2):
      fs/9p: track open fids
      fs/9p: search open fids first

 fs/9p/fid.c             |   46 +++++++++++++++++++++++++++++++++++++++++++++-
 fs/9p/fid.h             |    1 +
 fs/9p/vfs_dir.c         |    5 +++++
 fs/9p/vfs_file.c        |    1 +
 fs/9p/vfs_inode.c       |   10 +++++++++-
 fs/9p/vfs_inode_dotl.c  |    1 +
 include/net/9p/client.h |    3 +++
 net/9p/client.c         |    5 ++++-
 8 files changed, 69 insertions(+), 3 deletions(-)

--
Greg