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
On Tue, Dec 02, 2008 at 10:04:57AM -0800, Roman V. Shaposhnik wrote:
I would imagine that making '#p'/proc id/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,
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
since nfs is always directly mounted, i think you are confusing
direct mounts with things that are accessable because you have
mounted a server which has mounted something else.
I don't think I'm confusing anything here. In fact, your statement
of nfs is always directly mounted seems to be
I created a user nhh, and would just like to know how to set a password for
it.
I tried auth/changeuser nhh
and entered in all of the answers for each prompt.
still no password after the
user[nhh]:
prompt.
what do you mean by no password? your authentication
server will need to have
On Tue, 2008-12-02 at 14:29 -0500, erik quanstrom wrote:
i would think that either you want encapsulation or you don't.
see-through encapsulation would seem to me to be a contradiction
in terms.
Thanks for the feedback. Lets see if you change your mind after the
explanation given
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/id/ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the explanation
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/id/ns'
Thanks,
Roman.
P.S. Unless somebody tells me that it is a bad idea with the
nope. sorry. i would hate to see such a botch in plan 9.
if you want to distribute load by having multiple fs, then
it should be done so that the client wouldn't know or care
that any distribution is going on.
I think you're deliberately exaggerating here. You must
know full well,
Nolan,
how are you trying to connect to the Plan9? drawterm?
Plan9 do not request for a password on console.
Saludos.
Nolan Hamilton escribió:
I created a user nhh, and would just like to know how to set a
password for it.
I tried auth/changeuser nhh
and entered in all of the answers for
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 open
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
i'm sorry for what should be an obvious question.
does anyone know of a standalone netkey for unix,
mac or windows?
- erik
i have Charles's version here:
http://mirtchovski.com/p9/netkey.tgz
On Tue, Dec 2, 2008 at 5:09 PM, erik quanstrom [EMAIL PROTECTED] wrote:
i'm sorry for what should be an obvious question.
does anyone know of a standalone netkey for unix,
mac or windows?
- erik
/sys/src/cmd/unix/netkey.c
On 12/2/08, erik quanstrom [EMAIL PROTECTED] wrote:
i'm sorry for what should be an obvious question.
does anyone know of a standalone netkey for unix,
mac or windows?
- erik
--
Federico G. Benavento
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 by creating
On Tue, 2008-12-02 at 16:35 -0500, erik quanstrom wrote:
nope. sorry. i would hate to see such a botch in plan 9.
if you want to distribute load by having multiple fs, then
it should be done so that the client wouldn't know or care
that any distribution is going on.
I think
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 to,
On Tue, Dec 2, 2008 at 8:26 PM, Roman V. Shaposhnik [EMAIL PROTECTED] wrote:
The client does not pick. It is part of the automounter's decision.
And once the server gets picked by the automounter, it is awfully
convenient that you see the actual mount as part of the namespace.
Folks are
19 matches
Mail list logo
