Re: /etc/mtab and per-process namespaces

[Al Viro]

On Tue, Oct 04, 2005 at 01:07:48PM -0700, David Leimbach wrote:
> On 10/4/05, Al Viro <viro@xxxxxxxxxxxxxxxx> wrote:
> > On Tue, Oct 04, 2005 at 12:14:47PM -0700, David Leimbach wrote:
> > > Hmm no responses on this thread a couple days now.  I guess:
> > >
> > > 1) No one cares about private namespaces or the fact that they make
> > > /etc/mtab totally inconsistent.
> > > 2) Private Namespaces aren't important to anyone and will never be
> > > robust unless someone who cares, like me, takes it over somehow.
> > > 3) Everyone is busy with their own shit and doesn't want to deal with
> > > me or mine right now.
> >
> > 4) If you insist on having /etc/mtab the same file in all namespaces,
> > you obviously will have its contents not matching at least some
> > of them.  Either have it separate in each namespace where you want
> > to see it, or simply use /proc/self/mounts instead.
> 
> Well I guess it's my fault to some extent with the subject line.  I
> don't really care about /etc/mtab so much except that I'd like it to
> be consistent if it is going to be there.  I'd rather it do one of two
> things.  Show me my current process's namespace accurately or just the
> stuff that's global to all namespaces.  Right now it's kind of in
> between.

/etc/mtab is just a regular file; no more, no less.  It's a place used by
mount(8) and several other programs.  Kernel has nothing to do with it...

Obns: that can get tough.  Note that Plan 9 one is an approximation that
works well enough for most uses; if you play with mounting/unmounting/renaming
in sufficiently perverted ways, you'll get unusable /proc/<pid>/ns.  The
trouble being, they are luckier - they don't have to deal with many classes
of perversion we do, so their soluition wouldn't work well for Linux.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/