On Sat, Dec 6, 2008 at 12:24 AM, Roman Shaposhnik <[EMAIL PROTECTED]> wrote:
>> There are many things that would be *possible* with /proc, some of
>> them ill advised. For instance, why can't I 'mkdir /proc/n/' and have
>> it create a new process?
>
> There's an aswer to that given by Ken in the P
On Dec 2, 2008, at 5:36 PM, Dan Cross wrote:
On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom
<[EMAIL PROTECTED]> wrote:
currently one can prevent external changes to a
namespace by creating a unique ns with rfork.
if /proc/$pid/ns were writable, one would not not
be possible without yet another
On Tue, Dec 2, 2008 at 3:55 PM, Russ Cox <[EMAIL PROTECTED]> wrote:
>> a couple of questions come to mind. how does writing
>> to a ns interact with shared namespaces? does it automaticly
>> fork the namespace? seems iffy. which leads to the next
>> obvious question
>>
>> how do you prevent a r
On Tue, Dec 2, 2008 at 7:07 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> currently one can prevent external changes to a
> namespace by creating a unique ns with rfork.
> if /proc/$pid/ns were writable, one would not not
> be possible without yet another mechanism.
chmod? I guess it comes back
On Tue, 2008-12-02 at 19:07 -0500, erik quanstrom wrote:
> > None of these questions are any different in this
> > context than if there was simply some other process
> > sharing the name space and doing the same manipulations.
> >
>
> currently one can prevent external changes to a
> namespace b
> None of these questions are any different in this
> context than if there was simply some other process
> sharing the name space and doing the same manipulations.
>
currently one can prevent external changes to a
namespace by creating a unique ns with rfork.
if /proc/$pid/ns were writable, one
> a couple of questions come to mind. how does writing
> to a ns interact with shared namespaces? does it automaticly
> fork the namespace? seems iffy. which leads to the next
> obvious question
>
> how do you prevent a race between changing the namespace and
> opening fds?
>
> and, what about
> On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> > I still don't understand what kind of feature you are missing. Could
> > it be that you just want a naming convention for your mount places?
>
> Writable '#p//ns'
>
> Thanks,
> Roman.
>
> P.S. Unless somebody tells me that it is a bad idea wit
On Tue, 2008-12-02 at 21:05 +0100, hiro wrote:
> I still don't understand what kind of feature you are missing. Could
> it be that you just want a naming convention for your mount places?
Writable '#p//ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the explanation
to
> I *suspect* that this is, indeed, the dance Russ was referring to.
> Nothing wrong with dancing it. But it still leaves me curious
> as to why it was decided to *not* implement the support in the
> kernel.
>
> Thanks,
> Roman.
>
>
>
I still don't understand what kind of feature you are missing.
On Tue, 2008-12-02 at 13:31 -0500, Nathaniel W Filardo wrote:
> Namespaces form a large part of the security component of the Plan 9 model,
> and (AFAICT) cross-namespace work is underinvestigated
It would be, in fact, a fair answer.
> since it starts to look a lot like something that could compr
On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
> I would imagine that making '#p'//ns writable and receptive
> to messages of exact same format that is being output right now
> (plus an 'unmount X Y' message) would be a very natural thought in
> a Plan9 environment. Yet, it w
On Mon, 2008-12-01 at 16:18 -0500, Dan Cross wrote:
> On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> > In Plan9 land you don't need automounter to deal with
> > /media/floppy. But cd /net/ is not there.
> > At least not by default.
>
> I see what you're after. If
Hi, Russ!
Firs of all -- thank a lot for answering all of my question
in a very detailed manner. I really do appreciate it!
Now, if you don't mind, I still have just one question left:
On Mon, 2008-12-01 at 16:55 -0800, Russ Cox wrote:
> > That's very similar to what I referred to as a "synthetic
> Russ, could, you please be a tad more specific as to what ill
> exactly are you referring to?
I was referring to needing special privilege to mount something.
> While I agree that Plan9 completely removes the need for
> automounter to be a privileged application, I still don't
> see an easy way
On Mon, 01 Dec 2008 10:25:09 PST "Roman V. Shaposhnik" <[EMAIL PROTECTED]>
wrote:
>
> P.S. I have always wanted to be able to trade namespaces
> between different processes the same way file descriptors get
> traded using #s. On the other hand, I have never ever possessed
> enough insight into t
On Mon, Dec 1, 2008 at 1:31 PM, Roman V. Shaposhnik <[EMAIL PROTECTED]> wrote:
> In Plan9 land you don't need automounter to deal with
> /media/floppy. But cd /net/ is not there.
> At least not by default.
I see what you're after. If that's all you want, though, I have to
confess I don't see how
On Mon, 2008-12-01 at 10:17 -0800, ron minnich wrote:
> But this need for an automounter has not really existed for probably
> 17 years or so ... NFS servers are pretty reliable in many cases. It
> is interesting to see the use case for automoiuters change.
Right. I'm actually too young to be able
On Mon, 2008-12-01 at 09:48 -0800, Russ Cox wrote:
> The automounter is symptomatic of an ill that Plan 9 has cured.
> Since adding to the name space requires no special privileges,
> ordinary users can mount the servers they want to use directly,
> instead of needing a privileged daemon to guess t
On Mon, Dec 1, 2008 at 9:48 AM, Russ Cox <[EMAIL PROTECTED]> wrote:
> The automounter is symptomatic of an ill that Plan 9 has cured.
> Since adding to the name space requires no special privileges,
> ordinary users can mount the servers they want to use directly,
The other reason for an automount
The automounter is symptomatic of an ill that Plan 9 has cured.
Since adding to the name space requires no special privileges,
ordinary users can mount the servers they want to use directly,
instead of needing a privileged daemon to guess their intent and
mount servers on demand. In Plan 9, script
Maybe I missunderstood.
I mean that unless the server is reached in exaclty the same way
(which, in general, if you want something like automount, it does not)
aan is not enough.
It's fine to reach the same FS on the same address when the net goes
and come, but otherwise it is not IIRC.
On Mon, De
> bns != aan
>
> On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
> >> That's what bns does on Plan B.
> >> AFAIK, there's no way on Plan 9 to automate mounts making
> >> everythiing work after the FS goes away.
> >>
> >
> > aan?
well, sure. i wasn't saying that they are
bns != aan
On Mon, Dec 1, 2008 at 3:34 PM, erik quanstrom <[EMAIL PROTECTED]> wrote:
>> That's what bns does on Plan B.
>> AFAIK, there's no way on Plan 9 to automate mounts making
>> everythiing work after the FS goes away.
>>
>
> aan?
>
> - erik
>
>
> That's what bns does on Plan B.
> AFAIK, there's no way on Plan 9 to automate mounts making
> everythiing work after the FS goes away.
>
aan?
- erik
ans.net
> Reply-To: 9fans@9fans.net
> Date: Mon Dec 1 08:26:23 CET 2008
> Subject: [9fans] How to implement a moral equivalent of automounter in Plan9?
>
> Hi Guys!
>
> I've been trying to implement a "lazy bind/mount" in Plan9 and it
> dawned
Hi Guys!
I've been trying to implement a "lazy bind/mount" in Plan9 and it
dawned on
me that I don't really know any way of modifying calling process's
namespace
on-demand. In a automounter-like style.
Now, before you tell me that I shouldn't be doing it (well, may be I
shouldn't, but
pl
27 matches
Mail list logo