linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Al Viro <viro@ZenIV.linux.org.uk>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	linux-fsdevel <linux-fsdevel@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Christoph Hellwig <hch@infradead.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	Robo Bot <apw@canonical.com>, Felix Fietkau <nbd@openwrt.org>,
	Neil Brown <neilb@suse.de>, Jordi Pujol <jordipujolp@gmail.com>,
	ezk@fsl.cs.sunysb.edu, David Howells <dhowells@redhat.com>,
	Sedat Dilek <sedat.dilek@googlemail.com>,
	"J. R. Okajima" <hooanon05@yahoo.co.jp>
Subject: Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)
Date: Wed, 13 Mar 2013 18:52:49 +0000	[thread overview]
Message-ID: <20130313185249.GL21522@ZenIV.linux.org.uk> (raw)
In-Reply-To: <20130312222350.GK21522@ZenIV.linux.org.uk>

On Tue, Mar 12, 2013 at 10:23:50PM +0000, Al Viro wrote:

> I'll post a review tonight or tomorrow.  FWIW, I was not too happy with
> it the last time I looked, but I'll obviously need to reread the whole
> thing.

OK...  Here's the first pass at that:

* use of xattrs for whiteouts/opaque is a Bloody Bad Idea(tm).  That's one
thing you definitely can share with unionmount.  In particular, the games
with creds you have to pull off in ovl_do_lookup() are very clear indications
that xattr is simply a wrong interface for that.

* I don't see anything that would protect you from attacker playing silly
buggers with upper layer; mount it r/w elsewhere and do some renames...
Note that your ->lookup() relies on having the result of ovl_lookup_real()
remain the child of dentry we'd passed it as the first argument.  What's
there to guarantee that it will remain such?  The similar question goes for
malicious modifications of xattrs...  For that matter, what's to prevent
the same sucker mounted as upper layer in two places, with two unrelated lower
layers?  AFAICS, things will break rather badly if that happens, and I'm not
sure if you avoid deadlocks in such scenario...  Interfering with copyup
in progress is also possible.

* I think you might have an unpleasant problem in your ->setattr(); suppose
you've got through the checks in notify_change() and ovl_setattr() got called.
With ATTR_SIZE present.  OK, you do a truncated copyup; fair enough.  But
then you do notify_change() on upper layer dentry to do the rest of the job.
What happens if that fails?  Moreover, what's to prevent it being e.g. opened
by another process *before* you get around to that notify_change() part?

* ->follow_link():  Why the hell do you bother with struct ovl_link_data???
Just to avoid calling ovl_dentry_real() in ovl_put_link()?

BTW, a random note:
        if (err)
                return ERR_PTR(err);

        return NULL;
is a weird way to spell return ERR_PTR(err) - ERR_PTR(0) *is* NULL, TYVM,
and we rely on that in a lot of places.

  parent reply	other threads:[~2013-03-13 18:52 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-03-12 15:41 [PATCH 00/13] overlay filesystem: request for inclusion (v16) Miklos Szeredi
2013-03-12 15:41 ` [PATCH 01/13] vfs-add-i_op-dentry_open Miklos Szeredi
2013-03-12 15:41 ` [PATCH 02/13] vfs-export-do_splice_direct-to-modules Miklos Szeredi
2013-03-12 15:41 ` [PATCH 03/13] vfs-introduce-clone_private_mount Miklos Szeredi
2013-03-12 15:41 ` [PATCH 04/13] overlay filesystem Miklos Szeredi
2013-03-12 15:41 ` [PATCH 05/13] overlayfs-add-statfs-support Miklos Szeredi
2013-03-12 15:41 ` [PATCH 06/13] overlayfs-implement-show_options Miklos Szeredi
2013-03-12 15:41 ` [PATCH 07/13] overlay-overlay-filesystem-documentation Miklos Szeredi
2013-03-12 15:41 ` [PATCH 08/13] fs-limit-filesystem-stacking-depth Miklos Szeredi
2013-03-12 15:41 ` [PATCH 09/13] overlayfs-fix-possible-leak-in-ovl_new_inode Miklos Szeredi
2013-03-12 15:41 ` [PATCH 10/13] overlayfs-create-new-inode-in-ovl_link Miklos Szeredi
2013-03-12 15:41 ` [PATCH 11/13] vfs-export-inode_permission-to-modules Miklos Szeredi
2013-03-12 15:41 ` [PATCH 12/13] ovl-switch-to-inode_permission Miklos Szeredi
2013-03-12 15:41 ` [PATCH 13/13] overlayfs-copy-up-i_uid-i_gid-from-the-underlying-inode Miklos Szeredi
2013-03-12 16:49 ` [PATCH 00/13] overlay filesystem: request for inclusion (v16) Sedat Dilek
2013-03-12 20:00   ` Miklos Szeredi
2013-03-12 17:22 ` J. R. Okajima
2013-03-12 20:01   ` Miklos Szeredi
2013-03-12 21:50 ` Linus Torvalds
2013-03-12 22:23   ` Al Viro
2013-03-13  9:42     ` Sedat Dilek
2013-03-13 15:24     ` Miklos Szeredi
2013-03-13 18:52     ` Al Viro [this message]
2013-03-13 22:09       ` Miklos Szeredi
2013-03-13 23:19         ` Al Viro
2013-03-14 10:37           ` Miklos Szeredi
2013-03-14 12:57             ` DT_WHT (Re: [PATCH 00/13] overlay filesystem: request for inclusion (v16)) J. R. Okajima
2013-03-14 22:59             ` [PATCH 00/13] overlay filesystem: request for inclusion (v16) Al Viro
2013-03-18 11:27               ` Miklos Szeredi
2013-03-13 10:09 ` Sedat Dilek
2013-03-13 10:57   ` Miklos Szeredi
2013-03-20 19:41 George Spelvin
2013-03-20 21:32 ` Al Viro
2013-03-22  5:15 ` Rob Landley

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=20130313185249.GL21522@ZenIV.linux.org.uk \
    --to=viro@zeniv.linux.org.uk \
    --cc=akpm@linux-foundation.org \
    --cc=apw@canonical.com \
    --cc=dhowells@redhat.com \
    --cc=ezk@fsl.cs.sunysb.edu \
    --cc=hch@infradead.org \
    --cc=hooanon05@yahoo.co.jp \
    --cc=jordipujolp@gmail.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=nbd@openwrt.org \
    --cc=neilb@suse.de \
    --cc=sedat.dilek@googlemail.com \
    --cc=torvalds@linux-foundation.org \
    /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).