From: "H. Peter Anvin" <hpa@zytor.com>
To: Dax Kelson <dax@gurulabs.com>
Cc: autofs mailing list <autofs@linux.kernel.org>,
Mike Waychison <Michael.Waychison@Sun.COM>,
thockin@Sun.COM,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: name spaces good
Date: Tue, 06 Jan 2004 14:48:36 -0800 [thread overview]
Message-ID: <3FFB3B44.9060106@zytor.com> (raw)
In-Reply-To: <1073428129.2454.35.camel@mentor.gurulabs.com>
Dax Kelson wrote:
> On Tue, 2004-01-06 at 15:06, H. Peter Anvin wrote:
>
>>First of all, I'll be blunt: namespaces currently provide zero benefit
>>in Linux, and virtually noone uses them.
>
>
> I strongly disagree.
>
> I find them very useful, and there are lots of problems that are not
> cleanly solved any other way. In particular they are very useful in
> security hardening, compartmentalization scenarios.
>
Excellent... if so it would be useful to have a discussion about the
proper semantics for these scenarios. So far the consensus opinion
among most of the VFS people seems to have been "when you clone a
namespace you get an unanimated namespace"; it would be useful ito know
if that applies to your scenario, assuming it matters, and if so why/why
not.
Al Viro has been working on a key piece of infrastructure for doing
autofs right called mount traps. This is the main reason -- even more
so than the lack of time on my part -- that not much work has been done
on the new version of autofs. mount traps, combined with
"pseudo-symlinks" (non-S_IFLNK nodes which have follow_link methods), do
most of the tasks that have been proven necessary in the kernel.
The consensus I have seen seems to be that namespaces is mostly used, as
you said, for compartmentalizing and security, you pretty much have two
scenarios as far as I can see it:
a) You're running autofs "outside" the compartmentalization, in a global
namespace.
b) You're running autofs "inside" the compartmentalization, then you
don't want access to anything on the outside. You thus run the autofs
"inside" and can't access anything else.
-hpa
WARNING: multiple messages have this Message-ID (diff)
From: "H. Peter Anvin" <hpa@zytor.com>
To: Dax Kelson <dax@gurulabs.com>
Cc: thockin@Sun.COM, Mike Waychison <Michael.Waychison@Sun.COM>,
autofs mailing list <autofs@linux.kernel.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: name spaces good
Date: Tue, 06 Jan 2004 14:48:36 -0800 [thread overview]
Message-ID: <3FFB3B44.9060106@zytor.com> (raw)
In-Reply-To: <1073428129.2454.35.camel@mentor.gurulabs.com>
Dax Kelson wrote:
> On Tue, 2004-01-06 at 15:06, H. Peter Anvin wrote:
>
>>First of all, I'll be blunt: namespaces currently provide zero benefit
>>in Linux, and virtually noone uses them.
>
>
> I strongly disagree.
>
> I find them very useful, and there are lots of problems that are not
> cleanly solved any other way. In particular they are very useful in
> security hardening, compartmentalization scenarios.
>
Excellent... if so it would be useful to have a discussion about the
proper semantics for these scenarios. So far the consensus opinion
among most of the VFS people seems to have been "when you clone a
namespace you get an unanimated namespace"; it would be useful ito know
if that applies to your scenario, assuming it matters, and if so why/why
not.
Al Viro has been working on a key piece of infrastructure for doing
autofs right called mount traps. This is the main reason -- even more
so than the lack of time on my part -- that not much work has been done
on the new version of autofs. mount traps, combined with
"pseudo-symlinks" (non-S_IFLNK nodes which have follow_link methods), do
most of the tasks that have been proven necessary in the kernel.
The consensus I have seen seems to be that namespaces is mostly used, as
you said, for compartmentalizing and security, you pretty much have two
scenarios as far as I can see it:
a) You're running autofs "outside" the compartmentalization, in a global
namespace.
b) You're running autofs "inside" the compartmentalization, then you
don't want access to anything on the outside. You thus run the autofs
"inside" and can't access anything else.
-hpa
next prev parent reply other threads:[~2004-01-06 22:48 UTC|newest]
Thread overview: 79+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-01-06 19:55 [RFC] Towards a Modern Autofs Mike Waychison
2004-01-06 19:55 ` Mike Waychison
2004-01-06 21:01 ` H. Peter Anvin
2004-01-06 21:01 ` [autofs] " H. Peter Anvin
2004-01-06 21:44 ` Mike Waychison
2004-01-06 21:44 ` [autofs] " Mike Waychison
2004-01-06 21:50 ` Tim Hockin
2004-01-06 21:50 ` [autofs] " Tim Hockin
2004-01-06 22:06 ` H. Peter Anvin
2004-01-06 22:06 ` [autofs] " H. Peter Anvin
2004-01-06 22:17 ` Tim Hockin
[not found] ` <20040106221502.GA7398@hockin.org>
2004-01-06 22:20 ` H. Peter Anvin
2004-01-06 22:20 ` [autofs] " H. Peter Anvin
2004-01-07 16:19 ` Mike Waychison
2004-01-07 16:19 ` [autofs] " Mike Waychison
2004-01-07 17:55 ` H. Peter Anvin
2004-01-07 21:13 ` Mike Waychison
2004-01-06 22:28 ` name spaces good (was: [autofs] [RFC] Towards a Modern Autofs) Dax Kelson
2004-01-06 22:48 ` H. Peter Anvin [this message]
2004-01-06 22:48 ` name spaces good H. Peter Anvin
2004-01-07 21:14 ` [RFC] Towards a Modern Autofs Jim Carter
2004-01-07 21:14 ` [autofs] " Jim Carter
2004-01-07 22:55 ` Mike Waychison
2004-01-07 22:55 ` [autofs] " Mike Waychison
2004-01-08 12:00 ` Ian Kent
2004-01-08 12:00 ` [autofs] " Ian Kent
2004-01-08 15:39 ` Mike Waychison
2004-01-09 18:20 ` Ian Kent
2004-01-09 18:20 ` [autofs] " Ian Kent
2004-01-09 20:06 ` Mike Waychison
2004-01-09 20:06 ` [autofs] " Mike Waychison
2004-01-10 5:43 ` Ian Kent
2004-01-12 13:07 ` Mike Waychison
2004-01-12 16:01 ` raven
2004-01-12 16:26 ` Mike Waychison
2004-01-12 22:50 ` Tim Hockin
2004-01-12 23:28 ` Mike Waychison
2004-01-13 1:30 ` Ian Kent
2004-01-13 1:30 ` [autofs] " Ian Kent
2004-01-12 16:28 ` raven
2004-01-12 16:58 ` Mike Waychison
2004-01-13 1:54 ` Ian Kent
2004-01-13 1:54 ` [autofs] " Ian Kent
2004-01-13 19:01 ` Mike Waychison
2004-01-13 19:01 ` [autofs] " Mike Waychison
2004-01-14 15:58 ` raven
2004-01-14 19:32 ` running out of mount points Greg Bradner
2004-01-19 15:48 ` Greg Bradner
2004-01-19 17:11 ` Mike Waychison
2004-01-19 19:07 ` Greg Bradner
2004-01-20 19:15 ` Jim Carter
2004-01-13 18:46 ` [RFC] Towards a Modern Autofs Mike Waychison
2004-01-13 18:46 ` [autofs] " Mike Waychison
2004-01-09 20:51 ` Jim Carter
2004-01-09 20:51 ` [autofs] " Jim Carter
2004-01-10 5:56 ` Ian Kent
2004-01-08 17:34 ` H. Peter Anvin
2004-01-08 19:41 ` Mike Waychison
2004-01-08 23:42 ` Michael Clark
2004-01-09 20:28 ` Mike Waychison
2004-01-09 20:28 ` [autofs] " Mike Waychison
2004-01-09 20:54 ` H. Peter Anvin
2004-01-09 20:54 ` [autofs] " H. Peter Anvin
2004-01-09 21:43 ` Mike Waychison
2004-01-09 21:43 ` [autofs] " Mike Waychison
2004-01-09 18:32 ` Ian Kent
2004-01-09 18:32 ` [autofs] " Ian Kent
2004-01-09 20:52 ` Mike Waychison
2004-01-09 20:52 ` [autofs] " Mike Waychison
2004-01-10 6:05 ` Ian Kent
2004-01-08 12:29 ` Olivier Galibert
2004-01-08 13:20 ` Robin Rosenberg
2004-01-08 16:23 ` Mike Waychison
2004-01-08 12:35 ` Ian Kent
2004-01-08 13:08 ` Ian Kent
2004-01-08 18:20 ` Jim Carter
2004-01-08 21:01 ` H. Peter Anvin
2004-01-08 0:48 ` Ian Kent
2004-01-08 0:48 ` [autofs] " Ian Kent
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=3FFB3B44.9060106@zytor.com \
--to=hpa@zytor.com \
--cc=Michael.Waychison@Sun.COM \
--cc=autofs@linux.kernel.org \
--cc=dax@gurulabs.com \
--cc=linux-kernel@vger.kernel.org \
--cc=thockin@Sun.COM \
/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.