All of lore.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Pavel Machek <pavel@ucw.cz>
Cc: Miklos Szeredi <miklos@szeredi.hu>,
	serue@us.ibm.com, bfields@fieldses.org,
	linux-kernel@vger.kernel.org, viro@zeniv.linux.org.uk,
	linux-fsdevel@vger.kernel.org
Subject: Re: unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...)
Date: Fri, 27 Mar 2009 00:04:20 -0700	[thread overview]
Message-ID: <m163hvmop7.fsf@fess.ebiederm.org> (raw)
In-Reply-To: <20090326124338.GA1466@ucw.cz> (Pavel Machek's message of "Thu\, 26 Mar 2009 13\:43\:38 +0100")

Pavel Machek <pavel@ucw.cz> writes:

> 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?

That is a backwards understanding, of the problem.

Currently I can not delete my mount point if I have something mounted on it in another
mount namespace.

Generally lazy unmounts solve the deleted inodes problem, your were talking about.

Eric



  parent reply	other threads:[~2009-03-27  7:04 UTC|newest]

Thread overview: 58+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-03-11 12:53 VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? Igor Zhbanov
2009-03-11 23:23 ` J. Bruce Fields
2009-03-12 16:03   ` Serge E. Hallyn
2009-03-12 16:31     ` J. Bruce Fields
2009-03-12 16:10   ` Serge E. Hallyn
2009-03-12 19:00     ` J. Bruce Fields
2009-03-12 20:56       ` Igor Zhbanov
2009-03-12 20:21     ` Michael Kerrisk
2009-03-13 17:58       ` J. Bruce Fields
2009-03-13 18:37         ` Ответ: " Igor Zhbanov
2009-03-13 19:00           ` Serge E. Hallyn
2009-03-13 19:00             ` Serge E. Hallyn
2009-03-16 18:21             ` Stephen Smalley
2009-03-16 18:21               ` Stephen Smalley
2009-03-16 18:49               ` Serge E. Hallyn
2009-03-16 18:49                 ` Serge E. Hallyn
2009-03-16 21:00                 ` Stephen Smalley
2009-03-16 21:00                   ` Stephen Smalley
2009-03-16 22:26                   ` Igor Zhbanov
2009-03-16 23:13                   ` Serge E. Hallyn
2009-03-16 23:13                     ` Serge E. Hallyn
2009-03-16 23:17                     ` Igor Zhbanov
2009-03-17 14:20                     ` Stephen Smalley
2009-03-17 14:20                       ` Stephen Smalley
2009-03-17 17:39                       ` Serge E. Hallyn
2009-03-17 17:39                         ` Serge E. Hallyn
2009-03-17 17:52                         ` Stephen Smalley
2009-03-17 17:52                           ` Stephen Smalley
2009-03-17 18:23                           ` Serge E. Hallyn
2009-03-17 18:23                             ` Serge E. Hallyn
2009-03-18 16:17                             ` ?????: " Casey Schaufler
2009-03-18 16:17                               ` Casey Schaufler
2009-03-18 16:38                               ` Serge E. Hallyn
2009-03-18 16:38                                 ` Serge E. Hallyn
2009-03-18 16:21                             ` Ответ: " Stephen Smalley
2009-03-18 16:21                               ` Stephen Smalley
2009-03-18 16:47                               ` Serge E. Hallyn
2009-03-18 16:47                                 ` Serge E. Hallyn
2009-03-18 16:57                                 ` J. Bruce Fields
2009-03-18 17:24                                   ` Serge E. Hallyn
2009-03-18 17:24                                     ` Serge E. Hallyn
2009-03-16 22:48                 ` J. Bruce Fields
2009-03-16 23:03                   ` Serge E. Hallyn
2009-03-16 23:03                     ` Serge E. Hallyn
2009-03-14 19:20         ` Michael Kerrisk
2009-03-16 14:16           ` Igor Zhbanov
2009-03-16 16:36             ` J. Bruce Fields
2009-03-16 16:46               ` J. Bruce Fields
2009-03-16 17:05                 ` Serge E. Hallyn
2009-03-16 17:04               ` Serge E. Hallyn
2009-03-16 22:54                 ` J. Bruce Fields
2009-03-16 22:59                   ` Serge E. Hallyn
2009-03-23 13:21                 ` unprivileged mounts vs. rmdir (was: VFS, NFS security bug? ...) Miklos Szeredi
2009-03-26 12:43                   ` Pavel Machek
2009-03-26 13:14                     ` Matthew Wilcox
2009-03-27  7:04                     ` Eric W. Biederman [this message]
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]   ` <f44001920903120446k47590437q95242f7a55c11d57-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
2009-03-12 12:25     ` Igor Zhbanov

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=m163hvmop7.fsf@fess.ebiederm.org \
    --to=ebiederm@xmission.com \
    --cc=bfields@fieldses.org \
    --cc=linux-fsdevel@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=miklos@szeredi.hu \
    --cc=pavel@ucw.cz \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.