linux-fsdevel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Pavel Machek <pavel@ucw.cz>
To: Miklos Szeredi <miklos@szeredi.hu>
Cc: serue@us.ibm.com, bfields@fieldses.org,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	ebiederm@xmission.com, linux-fsdevel@vger.kernel.org
Subject: Re: unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...)
Date: Thu, 26 Mar 2009 13:43:38 +0100	[thread overview]
Message-ID: <20090326124338.GA1466@ucw.cz> (raw)
In-Reply-To: <E1Llk5q-0000kd-IR@pomaz-ex.szeredi.hu>

On Mon 2009-03-23 14:21:30, Miklos Szeredi wrote:
> [CCs trimmed]
> 
> On Mon, 16 Mar 2009, Serge E. Hallyn wrote:
> > Quoting J. Bruce Fields (bfields@fieldses.org):
> > > special privilege, so don't consult filesystem permissions (do I have
> > > that right?  What happened to the attempt to allow ordinary users to
> > > mount?).
> > 
> > Well, they keep getting stalled because we don't have a good answer for
> > what to do about the fact that an unprivileged user can make trees
> > undeletable by pinning them with mounts.  (Miklos and Eric cc'd in case
> > I didn't explain that well enough).
> 
> That's correct.
> 
> The best answer I can come up with is to allow rmdir/unlink to
> automatically umount trees from their respective dentries.  Obviously
> this can't be done for regular (privileged) mounts, which must keep
> returning EBUSY in such situations.
> 
> But for unprivileged mounts I can't see any fundamental issue with
> such an approach.
> 
> Does anyone see a problem with this?  Is there a better solution?

Well... traditionally if you have an open file or cwd inside mounted
tree... that blocks unmount, right?

What will you do with processes that have open (deleted) files inside
the mount? What about cwd?
								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

  reply	other threads:[~2009-03-26 12:43 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <f44001920903110553t52ce0ba7l4ba97213e1c51873@mail.gmail.com>
2009-03-12 11:46 ` VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
     [not found] ` <20090311232356.GP13540@fieldses.org>
     [not found]   ` <20090312161047.GA15209@us.ibm.com>
     [not found]     ` <517f3f820903121321sf6d2014q8165b925d5d44db7@mail.gmail.com>
     [not found]       ` <20090313175848.GB27891@fieldses.org>
     [not found]         ` <cfd18e0f0903141220u66230ceer22ef0cc6aed1d046@mail.gmail.com>
     [not found]           ` <f44001920903160716i488e3642o869f626a5c3327d0@mail.gmail.com>
     [not found]             ` <20090316163611.GB10959@fieldses.org>
     [not found]               ` <20090316170433.GA2996@us.ibm.com>
2009-03-23 13:21                 ` unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...) Miklos Szeredi
2009-03-26 12:43                   ` Pavel Machek [this message]
2009-03-26 13:14                     ` Matthew Wilcox
2009-03-27  7:04                     ` Eric W. Biederman

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=20090326124338.GA1466@ucw.cz \
    --to=pavel@ucw.cz \
    --cc=bfields@fieldses.org \
    --cc=ebiederm@xmission.com \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=serue@us.ibm.com \
    --cc=viro@zeniv.linux.org.uk \
    /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).