[9fans] File server for NT

[9fans] File server for NT

[Andrew Simmons]

Sorry to broadcast this, but I was trying to get through to Steve at
Snellwilcox, & got bounced back. Steve, if you're out there and still
interested I have a native NT equivalent of u9fs which seems to work pretty
well, although not extensively tested as yet. Probably available next week.

While I'm here, one puzzling thing I've noticed is that if I execute pwd or
ls under Plan 9, and the NT directory is say /c, then I get an attempted
walk to /c/pwd or /c/ls first. Is this the expected behaviour?

Re: [9fans] File server for NT

[Scott Schwartz]

| While I'm here, one puzzling thing I've noticed is that if I execute pwd or
| ls under Plan 9, and the NT directory is say /c, then I get an attempted
| walk to /c/pwd or /c/ls first. Is this the expected behaviour?

The shell's path is (. /bin) right?

Re: [9fans] File server for NT

[William Josephson]

On Fri, May 16, 2003 at 12:28:16PM +1200, Andrew Simmons wrote:
> While I'm here, one puzzling thing I've noticed is that if I execute pwd or
> ls under Plan 9, and the NT directory is say /c, then I get an attempted
> walk to /c/pwd or /c/ls first. Is this the expected behaviour?

What's your path?  As I recall, the default is to have .
at the head of it.

Re: [9fans] File server for NT

[Dan Cross]

Is having dot at the *beginning* of the path really that great
of an idea?  I've always wondered what was up with that.

	- Dan C.

Re: [9fans] File server for NT

[boyd, rounin]

> Is having dot at the *beginning* of the path really that great
> of an idea?  I've always wondered what was up with that.

it never was on lunix, but on plan 9 your path had to be:

   .
   /bin

to preserve some sort of semantic sanity, given 'everyone is a mortal' on plan
9.

or, maybe i'm missing something.

Re: [9fans] File server for NT

[rog]

> it never was on lunix, but on plan 9 your path had to be:
>
>    .
>    /bin
>
> to preserve some sort of semantic sanity, given 'everyone is a mortal' on plan
> 9.
>
> or, maybe i'm missing something.

i've been running with path=(/bin .)  for years under plan 9 with no
problems.

not only is it somewhat more secure, it's also a lot faster if you've
chdir'd to a slow external filesystem...  until you mistype a command!

i have no idea why the default is (.  /bin).

Re: [9fans] File server for NT

[Sam]

>
> i have no idea why the default is (.  /bin).
>

Just out of curiosity, how many times have
others found it useful to be able to specify
the "path" from $path?  Excluding the current
debate about the pecking order of dot ('cause
that's a good reason if folks fall on one of
two stakes), wouldn't it be less like Unix
and more like Plan 9 to do something like
have rc bind . to /bin for each cd?

... or is that just too wasteful?  The code
to parse the path is fairly small and fits
into the rest of the `struct word' semantics.
It's also not very good for rc's portability.
I suppose one could ignore the path given
in plan9.c:/Execute, but that's not going to
save much on code clarity.

Anyhow - just curious.

Sam

Re: [9fans] File server for NT

[ron minnich]

On Thu, 15 May 2003, Dan Cross wrote:

> Is having dot at the *beginning* of the path really that great
> of an idea?  I've always wondered what was up with that.

it's great if you're trying to social engineer somebody on Unix, right?
Sometimes it even wins you a free TV.

(For those who remember the Gould (I think) booth at one of the Unix
conventions long ago ... root had a path with '.' at the front, and
breaking in was just a matter of smooth-talking the sysadmin into cd-ing
somewhere and typing 'ls')

ron

Re: [9fans] File server for NT

[andrey mirtchovski]

On Fri, 16 May 2003, ron minnich wrote:

> (For those who remember the Gould (I think) booth at one of the Unix
> conventions long ago ... root had a path with '.' at the front, and
> breaking in was just a matter of smooth-talking the sysadmin into cd-ing
> somewhere and typing 'ls')
>

I think that story was described in the introductory chapters of
"Practical UNIX and Internet Security" by Spafford and Garfinkel.. (Just
like the arianne rocket disaster everyone talked about so much recently
is given as a case in point in Chapter 6 of TPOP.)

To throw in my $0.02 -- I've always explained (. /bin) to myself with the fact
that it's a very convenient thing not to have to type "./" every time (though I
still get caught doing it ;) and as far as security goes it's pretty much
irrelevant -- it's all contained within the private namespace of that user and
as soon as that goes away...

Yes, there are many nasty things one can do, but they're not nearly as bad
as having an 'ls' in the current directory doing 'cp /bin/sh /tmp/...; chmod
4755 /tmp/...'

What are the chances (. /bin) is this way just to irritate your average unix
security expert?

andrey

Re: [9fans] File server for NT

[Dan Cross]

> that it's a very convenient thing not to have to type "./" every time (though
> I still get caught doing it ;) and as far as security goes it's pretty much
> irrelevant -- it's all contained within the private namespace of that user and
> as soon as that goes away...

Yeah, but just because the namespace is private to you doesn't mean that
someone can't put something nasty in it.  ``Hey Andrey, there's something
weird in my home directory; would you mind taking a look at it?''

	- Dan C.

Re: [9fans] File server for NT

[boyd, rounin]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]

"Dan Cross" <cross@math.psu.edu> a �crit dans le message de
news:200305161602.h4GG27512619@augusta.math.psu.edu...
> Yeah, but just because the namespace is private to you doesn't mean that
> someone can't put something nasty in it.

yup, and with these 'modern' lunix shells, typing:

    /bin/su

is no longer guaranteed to do what it would do, when i were a lad ...

Re: [9fans] File server for NT

[Russ Cox]

If path were (/bin .) we'd be having a discussion
about how stupid it was that if someone put an 8.out
in /386/bin you wouldn't be able to run recently compiled
programs.  To each his own.

Re: [9fans] File server for NT

[ron minnich]

On Fri, 16 May 2003, andrey mirtchovski wrote:

> To throw in my $0.02 -- I've always explained (. /bin) to myself with
> the fact that it's a very convenient thing not to have to type "./"
> every time (though I still get caught doing it ;) and as far as security
> goes it's pretty much irrelevant -- it's all contained within the
> private namespace of that user and as soon as that goes away...


that's why I think of it as a Unix issue only.

ron

Re: [9fans] File server for NT

[Geoff Collyer]

Like rog, I've been running with path=(/bin .) for years, since I
noticed attempts by rc to walk into DOS and remotely-served file
systems when looking for commands.

The things that make set-id programs found by "." in PATH on Unix so
dangerous are the relatively immutable namespace of a given Unix
system and the power that can be achieved via set-id execution.  Since
the namespace is essentially unchangeable, evildoers can accurately
predict where files will be found when their trojan horse runs.  Plan
9 offers less predictability, and one could drastically rearrange
one's namespace when running a suspect program (though obviously this
doesn't apply to trojan horses).  For example, run ramfs, copy the
binary into /tmp, unmount and unbind as much as possible, notably /,
/bin and /srv, and run the program in /tmp.  Since Plan 9 doesn't have
set-id execution, the worst a trojan horse can do is run as the user
who invokes it, which admittedly can be bad news for that user, but it
does limit the potential damage considerably.

Re: [9fans] File server for NT

[northern snowfall]

>
>
>Plan9 offers less predictability, and one could drastically rearrange
>one's namespace when running a suspect program (though obviously this
>doesn't apply to trojan horses).
>
Unless, of course, the trojan or malicious code runs newns
and creates a default namespace. Then, you can regain a
decent sense of reliability.
Don

Re: [9fans] File server for NT

[Geoff Collyer]

It was just an example, not a bullet-proof recipe.  I knew I should
have mentioned "rfork m", which lets you prevent the malicious code
from mounting anything useful.  So one can still prevent malicious
code from having predictable non-degenerate namespaces.

Re: [9fans] File server for NT

[Andrew Simmons]

> The shell's path is (. /bin) right?

Sorry to be obtuse, but are you saying that 9fs is attempting to run pwd or
ls on the remote system running u9fs?

Re the path name, I have to confess I only looked at it after I'd
re-formatted it, possibly erroneously, but I'm confused about the references
to dot. From walk(5): The name "." (dot), meaning the current directory, is
not used in the protocol.

Re: [9fans] File server for NT

[William K. Josephson]

On Fri, May 16, 2003 at 03:53:16PM +1200, Andrew Simmons wrote:
> Sorry to be obtuse, but are you saying that 9fs is attempting to run pwd or
> ls on the remote system running u9fs?

No, your shell.  When you tell the shell to execute 'foo', it
will, for each directory, d, in the path, try to execute d/foo.
It so happens that by default the first directory in the path
is ..

> Re the path name, I have to confess I only looked at it after I'd
> re-formatted it, possibly erroneously, but I'm confused about the references
> to dot. From walk(5): The name "." (dot), meaning the current directory, is
> not used in the protocol.

The protocol has nothing to do with it; you're just seeing an
artifact of how the shell works.

Re: [9fans] File server for NT

[William K. Josephson]

On Fri, May 16, 2003 at 01:00:16AM -0400, William K. Josephson wrote:
> On Fri, May 16, 2003 at 03:53:16PM +1200, Andrew Simmons wrote:
> > Sorry to be obtuse, but are you saying that 9fs is attempting to run pwd or
> > ls on the remote system running u9fs?
>
> No, your shell.  When you tell the shell to execute 'foo', it
> will, for each directory, d, in the path, try to execute d/foo.
> It so happens that by default the first directory in the path
> is ..

And before some wise-guy points it out, of course
I meant '"."'.

Re: [9fans] File server for NT

[Andrew Simmons]

in article 20030516050016.GA69277@mero.morphisms.net, William K. Josephson
at jkw@eecs.harvard.edu wrote on 5/16/03 5:01 PM:

> On Fri, May 16, 2003 at 03:53:16PM +1200, Andrew Simmons wrote:
>> Sorry to be obtuse, but are you saying that 9fs is attempting to run pwd or
>> ls on the remote system running u9fs?
>
> No, your shell.  When you tell the shell to execute 'foo', it
> will, for each directory, d, in the path, try to execute d/foo.
> It so happens that by default the first directory in the path
> is ..
>
>> Re the path name, I have to confess I only looked at it after I'd
>> re-formatted it, possibly erroneously, but I'm confused about the references
>> to dot. From walk(5): The name "." (dot), meaning the current directory, is
>> not used in the protocol.
>
> The protocol has nothing to do with it; you're just seeing an
> artifact of how the shell works.
>
I think we're talking at cross-purposes here. I'm running Windows 2000, and
don't knowingly have a shell as such. I'm running Plan 9 in a VMWare virtual
machine, talking to an NT service similar to u9fs on the same physical
machine. In the Plan 9 VM, I connect to the NT service by typing something
like:
9fs ajs
I then authenticate via 9pany if necessary. After that, the drives on my
machine are visible from the Plan 9 VM as /n/ajs/c and so on. If my current
directory on the Plan 9 VM is /n/ajs/c/nurdge, and I execute the command
pwd, then the first thing that seems to happen in the NT service is that I
get a 9p2000 message to walk to /n/ajs/c/nurdge/pwd. This fails, but the pwd
command eventually produces the right result. Similarly with the ls command.
What I was trying to find out is, does 9fs send the walk messages I have
attempted to describe? If so, why? If not, am I hallucinating?

Re: [9fans] File server for NT

[Russ Cox]

> machine are visible from the Plan 9 VM as /n/ajs/c and so on. If my current
> directory on the Plan 9 VM is /n/ajs/c/nurdge, and I execute the command
> pwd, then the first thing that seems to happen in the NT service is that I
> get a 9p2000 message to walk to /n/ajs/c/nurdge/pwd. This fails, but the pwd
> command eventually produces the right result. Similarly with the ls command.
> What I was trying to find out is, does 9fs send the walk messages I have
> attempted to describe? If so, why? If not, am I hallucinating?

As everyone else said, when you type "pwd" your shell searches
your path -- (. /bin) -- for the binary to run.  This means it
tries to access "./pwd" and then "/bin/pwd".  The first turns into
"/n/ajs/c/nurdge/pwd" since . is "/n/ajs/c/nurdge".

You can simulate this manually by typing "./pwd; /bin/pwd".
Also, if you typed "/bin/pwd" directly, then you wouldn't see
any traffic.

Re: [9fans] File server for NT

[Andrew Simmons]

>
> As everyone else said, when you type "pwd" your shell searches
> your path -- (. /bin) -- for the binary to run.  This means it
> tries to access "./pwd" and then "/bin/pwd".  The first turns into
> "/n/ajs/c/nurdge/pwd" since . is "/n/ajs/c/nurdge".
>
> You can simulate this manually by typing "./pwd; /bin/pwd".
> Also, if you typed "/bin/pwd" directly, then you wouldn't see
> any traffic.
>

Thanks, I finally understand now you've explained it in words of one
syllable. Apologies to all for being so slow. I think I should stick to
using a Mac in future.

Re: [9fans] File server for NT

[rog]

> I think we're talking at cross-purposes here. I'm running Windows 2000, and
> don't knowingly have a shell as such.

the shell is the thing you're typing "pwd" to!

Re: [9fans] File server for NT

[Keith Nash]

> it never was on lunix, but on plan 9 your path had to be:
>
>    .
>    /bin
>
> to preserve some sort of semantic sanity, given 'everyone is a mortal' on
> plan 9.

Putting "." at the head of the path means that a system tool will be overridden by anything in the current directory that happens to have the same name.  This practice is not advised in Lunix; I have often wondered why it was adopted in Plan 9.

Telling Plan 9 to execute dir/tool causes it to look for $path/dir/tool, not ./dir/tool - a consistent and elegant choice of design.

I'm not sure whether by 'semantic sanity' you mean preserving an aspect of Lunix' inconsistency in order to provide users with a familiar environment.  This isn't the choice that Plan 9's designers usually made.

Does anything break if path is set to just "/bin", or to "/bin ."?  For example, in
cd foo
mk
developers are free to place their own substitutes for system commands along with their source files in directory foo.  Does the official Plan 9 software ever do this?  Even if it doesn't, 3rd-party software might, which suggests that we are stuck with using the ". /bin" default for ever.