From: Remi Turk <remi@a2zis.com>
To: linux-kernel@vger.kernel.org
Subject: CLONE_NAMESPACE, links for dirs and mount(2) for normal users questions
Date: Sat, 25 Nov 2000 18:43:08 +0100 [thread overview]
Message-ID: <3A1FFA2C.A8980FD8@a2zis.com> (raw)
Hi,
Long long ago, (March 2000) Alexander Viro replied to Pavel Machek:
>> Am I right that from now on each process can have completely different
>> view of filesystem like in plan9?
>
>Almost there ;-) And yes, the only thing we lack for proper namespaces is
>the union-directories (clone() bit is trivial).
Are there any patches already?
If not, where should I start to implement them?
Probably related to the first question, what about allowing mount(2)
(as a CONFIG-option) for normal user processes when they
have a) rw access to the device and b) are the owner/have rw-access
to the mountpoint. (There would be at least one security problem:
A normal user could mount a loopback ext2 filesystem with
panic-on-error (man tune2fs) and then corrupt it)
In April, Al Viro wrote:
> 1. We should never have more than one dentry for a writable directory.
>
> Print it and hang it on the wall. It's a fundamental requirement. There is
> no way to work around it in our VFS. I tried to invent a scheme that would
> allow that for more than a year. And I've done most of namespace-related code
> in our VFS since the moment when Bill Hawes stopped working on it, so I suspect
> that right now I have the best working knowledge of that stuff. There is no
> fscking way to survive multiple dentries for writable directory without major
> lossage. Period.
Do I understand correctly that this means hardlinks to directories
(except . and ..) are fundamentally impossible in Linux?
(I'm thinking about trying to write a garbage collected
filesystem with hardlinks to directories.)
--
Linux 2.4.0-test11 #1 Mon Nov 20 17:19:26 CET 2000
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/
next reply other threads:[~2000-11-25 18:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-11-25 17:43 Remi Turk [this message]
2000-11-29 3:13 ` CLONE_NAMESPACE, links for dirs and mount(2) for normal users questions Peter Samuelson
2000-11-30 6:31 ` Remi Turk
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=3A1FFA2C.A8980FD8@a2zis.com \
--to=remi@a2zis.com \
--cc=linux-kernel@vger.kernel.org \
/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.