public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Mike Waychison <michael.waychison@sun.com>
To: David Howells <dhowells@warthog.cambridge.redhat.com>
Cc: viro@parcelfarce.linux.theplanet.co.uk,
	David Howells <dhowells@redhat.com>,
	Linus Torvalds <torvalds@transmeta.com>,
	Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] VFS autmounter support v2
Date: Thu, 19 Jun 2003 10:00:40 -0400	[thread overview]
Message-ID: <3EF1C208.1080404@sun.com> (raw)
In-Reply-To: <fa.fq0dsjb.1a06mop@ifi.uio.no>

David Howells wrote:
> 
> I think this can make use of my suggested change... If you make a trigger fs
> that has its root directory simply an automount point (though this leads me to
> think that perhaps (u)mount should follow the example of stat and use
> LOOKUP_NOAUTOMOUNT).
> 
> Perhaps:
> 
> 	[namespace X]
> 	mount /dev/hda8 /usr/include
> 	mount -t trap "mount-fs-B" /usr/include/foo1
> 	mount -t trap "mount-fs-C" /usr/include/foo2
> 
> 	[namespace Y]
> 	mount /dev/hda8 /usr/local/include
> 	mount -t trap "mount-fs-D" /usr/local/include/foo1
> 
> Then have a daemon that can take a request to mount and then reply with the
> mount parameters, allowing the trap fs to obtain a vfsmount via
> do_kern_mount(). I would make the trap fs supply the daemon with an fd
> attached to the trap rootdir to act as a token representing the request (and
> controlling its lifetime).
> 

You would have to go this route.  I think Al's opinion in this is that 
your original proposal allows arbitrary dentry's in the tree to act as 
traps.  As such, there is no way for a derived namespace to manipulate 
that trap at all.  By implying that the trap is installed via mount says 
you are now proposing that every trap is represented by its own superblock.

You're new proposal is exactly what I have been working on, autofs 
direct mountpoints using the less intrusive follow_link magic Anvin has 
mentioned on a previous thread both here and on autofs@vger.

The one problem with this solution is the following breaks:

# installtrap /foo host:/export/foo
<userspace daemon listens for requests to mount>
# newnssh
newnssh # cd /foo

Oops, the daemon started from the initial namespace doesn't have access 
to the namespace in my second shell.

The most reasonable way I can see to cope with this is to allow 
CAP_SYS_ADMIN processes the ability to change namespaces.  Eg, the 
daemon can be told which pid triggered the trap on /foo, 
open(/proc/<pid>/mounts) and perform a ioctl(IOC_USENAMESPACE) on it.

What do you guys think?

Mike Waychison


       reply	other threads:[~2003-06-19 13:50 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <fa.nerig52.1j7u3qk@ifi.uio.no>
     [not found] ` <fa.fq0dsjb.1a06mop@ifi.uio.no>
2003-06-19 14:00   ` Mike Waychison [this message]
2003-06-19 14:31     ` [PATCH] VFS autmounter support v2 David Howells
2003-06-19 15:13       ` Mike Waychison
2003-06-19 15:34         ` viro
2003-06-19 16:53           ` Mike Waychison
2003-06-18 14:20 David Howells
2003-06-18 20:59 ` viro
2003-06-19  9:46   ` David Howells
2003-06-19 14:55     ` viro

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=3EF1C208.1080404@sun.com \
    --to=michael.waychison@sun.com \
    --cc=dhowells@redhat.com \
    --cc=dhowells@warthog.cambridge.redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@transmeta.com \
    --cc=viro@parcelfarce.linux.theplanet.co.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