linux-kernel - Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

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: <CA+55aFxd_jSc75pfhNQ6jTbwcQkDfNqALMNThYtgBsH0Z7tA4Q@mail.gmail.com>
Date:	Fri, 15 Mar 2013 12:11:21 -0700
From:	Linus Torvalds <torvalds@...ux-foundation.org>
To:	"J. R. Okajima" <hooanon05@...oo.co.jp>
Cc:	Al Viro <viro@...iv.linux.org.uk>,
	Miklos Szeredi <miklos@...redi.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-fsdevel <linux-fsdevel@...r.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Christoph Hellwig <hch@...radead.org>,
	Robo Bot <apw@...onical.com>, Felix Fietkau <nbd@...nwrt.org>,
	Neil Brown <neilb@...e.de>,
	Jordi Pujol <jordipujolp@...il.com>, ezk@....cs.sunysb.edu,
	David Howells <dhowells@...hat.com>,
	Sedat Dilek <sedat.dilek@...glemail.com>,
	Miklos Szeredi <mszeredi@...e.cz>
Subject: Re: [PATCH 0/9] overlay filesystem: request for inclusion (v17)

On Thu, Mar 14, 2013 at 10:09 PM, J. R. Okajima <hooanon05@...oo.co.jp> wrote:
>
> "no inodes at all"?
> Are you assuming the implementation in dcache only (with a new d_type
> flag)? And it is up to the real fs (layer or branch) whether it consumes
> inode or not?

Yes. That would be lovely. And trivial for most filesystems to support.

Sure, you could have an inode if you need to (not all filesystems may
have a flag in the directory entry), so it would look like "mknod()"
for the filesystem. But the filesystem might decide to never actually
create the inode at all if it reconizes the node as a whiteout node.

I think we should do this. Yes, it requires filesystem work, but in
the long run it's the right thing to do, and the filesystem work is
likely very very simple. Besides, we probably only need to support a
few filesystems for it to be already useful. What filesystems do the
people who use unionfs actually use today?

Also note that it's only the "upper layer" filesystem that needs
whiteout nodes. So it's not "all filesystems involved with overlayfs",
it's only the upper ones. And they have to already support xattr, so
I'm assuming in practice we're talking only a few cases, right? Just
tmpfs, ext3, ext4 probably covers most cases..

And it would get rid of all the horrible security check changes for
xattrs, no? So we'd really end up with a noticeably cleaner model.

              Linus
--
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/