[9fans] several things

[9fans] several things

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 1234 bytes --]

Hello

few questions:

1) Having a window with rc and pressing CTRL+d usually closes the window.
However, from time to time it does not. Instead, I can see EOT (one
character; diagonally) written after the prompt, the window stays, I can
write anything into the window, but my commands are not executed. When does
this happen?

2) Reading pwd.c I can see 'char pathname[512]' at the beginning of the main
function. Does it mean plan9 paths are thus limited?

3) Why do I have to press END key several times to get to the bottom of a
window (usu when there is a lot of output text from the issued command)?
(The rio maunual says just one press.)

4) What is the sense of
bind 'sth' 'the_same_sth'
? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')

5) When I do

cd
mkdir a
mntgen a
bind lib a/b
unmount a

all these command finish ok, but I am left with

bind /usr/ruda/lib /usr/ruda/a/b

in the namespace (see the result of the 'ns' command; there you can also
spot that after issueing the 'mntgen' command a line
'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
this bind is the one removed by the 'unmount' command).
How can I get rid of that then?

Thanks
Ruda

[-- Attachment #2: Type: text/html, Size: 1400 bytes --]

Re: [9fans] several things

[erik quanstrom]

> 1) Having a window with rc and pressing CTRL+d usually closes the window.
> However, from time to time it does not. Instead, I can see EOT (one
> character; diagonally) written after the prompt, the window stays, I can
> write anything into the window, but my commands are not executed. When does
> this happen?

this generally happens when you have mounted a fileserver which doesn't
close all of rio's fds (inherited from the rc you terminated).  rio considers
the window active until all the fds are closed.

> 2) Reading pwd.c I can see 'char pathname[512]' at the beginning of the main
> function. Does it mean plan9 paths are thus limited?

no.  fileservers evaludate the path one element at a time.


> 3) Why do I have to press END key several times to get to the bottom of a
> window (usu when there is a lot of output text from the issued command)?
> (The rio maunual says just one press.)

if you notice that once you are at the end, you can press
<home> then <end> and you will be at the end.  so what's
happening when you press <end> when there's pending output
is that you're placed at the end of the buffer but since the command
producing the output blocked on its output, it immediately started
outputting more data.  so <end> always puts you at the the
*current* end of the buffer.  that doesn't mean that there won't
be data immediately available.

> 4) What is the sense of
> bind 'sth' 'the_same_sth'
> ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')

i believe this is a noop.  in the case of "bind / /", look
at /lib/namespace.  consider the case where $rootdir
isn't nil.

> 5) When I do
>
> cd
> mkdir a
> mntgen a
> bind lib a/b
> unmount a
>
> all these command finish ok, but I am left with
>
> bind /usr/ruda/lib /usr/ruda/a/b
>
> in the namespace (see the result of the 'ns' command; there you can also
> spot that after issueing the 'mntgen' command a line
> 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
> this bind is the one removed by the 'unmount' command).
> How can I get rid of that then?

i don't think any pruning of inaccessable bits of
the namespace is ever done.  consider a program
like ftpd which via /lib/namespace.ftp (sic) typically
binds something like /usr/ftp/ onto /.  while everything
above /usr/ftp is unaccessable, it's not removed from
the namespace and you can't touch it.

	; mntgen a
	; bind /env a/env
	; bind /bin a/bin
	; bind /proc a/proc
	; bind a /
	; ns

consider it a security feature.

- erik

Re: [9fans] several things

[Pietro Gagliardi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Oct 13, 2008, at 5:35 PM, Rudolf Sykora wrote:

> Hello
>
> few questions:
>
> 1) Having a window with rc and pressing CTRL+d usually closes the
> window. However, from time to time it does not. Instead, I can see
> EOT (one character; diagonally) written after the prompt, the window
> stays, I can write anything into the window, but my commands are not
> executed. When does this happen?

When you're running a server, such as ext2srv or dossrv. If I recall
correctly, this was discussed before.

> 2) Reading pwd.c I can see 'char pathname[512]' at the beginning of
> the main function. Does it mean plan9 paths are thus limited?

No. How many characters can be stored in an absolute pathname is
program-dependent.

> 3) Why do I have to press END key several times to get to the bottom
> of a window (usu when there is a lot of output text from the issued
> command)?
> (The rio maunual says just one press.)

rio windows don't scroll by default. To enable scrolling for a certain
window, middle-click and hit scroll, or type

	echo scroll >/dev/wctl

To make scrolling the default, edit $home/lib/profile and change every
instance of

	exec rio

to

	exec rio -s

Log out and log back in.

> 4) What is the sense of
> bind 'sth' 'the_same_sth'
> ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')

Think of it as making an alias or link.

> 5) When I do
>
> cd
> mkdir a
> mntgen a
> bind lib a/b
> unmount a
>
> all these command finish ok, but I am left with
>
> bind /usr/ruda/lib /usr/ruda/a/b
>
> in the namespace (see the result of the 'ns' command; there you can
> also spot that after issueing the 'mntgen' command a line
> 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th
> question; this bind is the one removed by the 'unmount' command).
> How can I get rid of that then?

Delete the namespace by closing the window.

You just found a bug; congratulations.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkjz0Q8ACgkQuv7AVNQDs+yPUgCePQ1xijeQfxMC8iWZPuzNGCxH
gCMAnR636iteBBjHhYLW4rdKjfIVIkj8
=aCUq
-----END PGP SIGNATURE-----

Re: [9fans] several things

[Rudolf Sykora]

[-- Attachment #1: Type: text/plain, Size: 479 bytes --]

> > 2) Reading pwd.c I can see 'char pathname[512]' at the beginning of the
> main
> > function. Does it mean plan9 paths are thus limited?
>
> no.  fileservers evaludate the path one element at a time.
>  - erik
>

But at least it means that the 'pwd' function returns a wrong answer
_without_warning_ when the path is longer. I tried it. This is not a nice
thing. Are these limitations listed in some document?
Ruda

ps.: thanks otherwise for your other answers.

[-- Attachment #2: Type: text/html, Size: 780 bytes --]

Re: [9fans] several things

[Steve Simon]

> Are these limitations listed in some document?

I don't believe they are.

It might bve nice to think there are no arbitary limits in plan9
as the GNU mantra, however there are not many and personally,
working with remote servers with very long paths, I have never
(knowingly) hit this limit.

Having said this we could probably afford to up the size of pwd's
buffer to, say, 8k to be sixteen times as sure.

-Steve

Re: [9fans] several things

[Yaroslav]

> But at least it means that the 'pwd' function returns a wrong answer
> _without_warning_ when the path is longer. I tried it. This is not a nice
> thing. Are these limitations listed in some document?

The pwd(1) utility has this limitation for simplicity. The getwd(2)
function and fd2path(2) syscall can work on arbitrary-sized buffers.
So, to overcome the limit, you have few choices:
 1) modify the pwd.c to allocate more memory; or
 2) bind not-so-long parts of your path to /n/something to construct a
namespace with shorter absolute paths; or
 3) blame the tree holders.

--
Best regards,
    Yaroslav.

Re: [9fans] several things

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 345 bytes --]

fd2path should probably complain if the buffer is too small.
i'm surprised at any actual name longer than 512 (or even 256), not so much for plan 9, but
because linux systems still seem to have that tiny TTY limit on the size of an input line,
or it did the last time i tried to use the mouse to snarf and send a command line printed by make.

[-- Attachment #2: Type: message/rfc822, Size: 2750 bytes --]

From: Yaroslav <yarikos@gmail.com>
To: "Fans of the OS Plan 9 from Bell Labs" <9fans@9fans.net>
Subject: Re: [9fans] several things
Date: Tue, 14 Oct 2008 15:22:10 +0300
Message-ID: <e2f969e10810140522r4e874ef1n9f63d3cced7d53bf@mail.gmail.com>

> But at least it means that the 'pwd' function returns a wrong answer
> _without_warning_ when the path is longer. I tried it. This is not a nice
> thing. Are these limitations listed in some document?

The pwd(1) utility has this limitation for simplicity. The getwd(2)
function and fd2path(2) syscall can work on arbitrary-sized buffers.
So, to overcome the limit, you have few choices:
 1) modify the pwd.c to allocate more memory; or
 2) bind not-so-long parts of your path to /n/something to construct a
namespace with shorter absolute paths; or
 3) blame the tree holders.

--
Best regards,
    Yaroslav.

Re: [9fans] several things

[Derek Fawcus]

On Tue, Oct 14, 2008 at 02:15:15PM +0100, Charles Forsyth wrote:
> i'm surprised at any actual name longer than 512 (or even 256), not so much for plan 9, but
> because linux systems still seem to have that tiny TTY limit on the size of an input line,

err - I seem to recall reading some linux pty/tty source that implied a larger limit in
canonical mode - 4k/8k?  But that assumes the shells in question _use_ cannonical mode.

Re: [9fans] several things

[Charles Forsyth]

>But that assumes the shells in question _use_ cannonical mode.

most of them use readline, so that might explain it.

Re: [9fans] several things

[Roman V. Shaposhnik]

On Mon, 2008-10-13 at 18:35 -0400, erik quanstrom wrote:
> > 4) What is the sense of
> > bind 'sth' 'the_same_sth'
> > ? (like 'bind / /' or 'bind /usr/ruda/a /usr/ruda/a')
>
> i believe this is a noop.  in the case of "bind / /", look
> at /lib/namespace.  consider the case where $rootdir
> isn't nil.

I have always thought, that the only reason for "bind <foo> <foo>"
is so that subsequent "bind -a/-b" would work:
   http://groups.google.com/group/comp.os.plan9/browse_thread/thread/c6cc9fb882978983/5067403b25124bac?hl=en&lnk=gst&q=bind+#5067403b25124bac

I would really love to be educated is there's something more
subtle to it.

> > 5) When I do
> >
> > cd
> > mkdir a
> > mntgen a
> > bind lib a/b
> > unmount a
> >
> > all these command finish ok, but I am left with
> >
> > bind /usr/ruda/lib /usr/ruda/a/b
> >
> > in the namespace (see the result of the 'ns' command; there you can also
> > spot that after issueing the 'mntgen' command a line
> > 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th question;
> > this bind is the one removed by the 'unmount' command).
> > How can I get rid of that then?
>
> i don't think any pruning of inaccessable bits of
> the namespace is ever done.  consider a program
> like ftpd which via /lib/namespace.ftp (sic) typically
> binds something like /usr/ftp/ onto /.  while everything
> above /usr/ftp is unaccessable, it's not removed from
> the namespace and you can't touch it.
>
> 	; mntgen a
> 	; bind /env a/env
> 	; bind /bin a/bin
> 	; bind /proc a/proc
> 	; bind a /
> 	; ns
>
> consider it a security feature.

Be it as it may, I still can't quite follow why *manual* pruning
of the entries from the namespace would be forbidden. unmount(2)
takes two strings as arguments, right? It doesn't even need an fd.

Thanks,
Roman.

Re: [9fans] several things

[erik quanstrom]

> > 	; mntgen a
> > 	; bind /env a/env
> > 	; bind /bin a/bin
> > 	; bind /proc a/proc
> > 	; bind a /
> > 	; ns
> >
> > consider it a security feature.
>
> Be it as it may, I still can't quite follow why *manual* pruning
> of the entries from the namespace would be forbidden. unmount(2)
> takes two strings as arguments, right? It doesn't even need an fd.

because they're not visible.  you have to access
it in order to unmount it.

- erik

Re: [9fans] several things

[Roman V. Shaposhnik]

On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
> > > 	; mntgen a
> > > 	; bind /env a/env
> > > 	; bind /bin a/bin
> > > 	; bind /proc a/proc
> > > 	; bind a /
> > > 	; ns
> > >
> > > consider it a security feature.
> >
> > Be it as it may, I still can't quite follow why *manual* pruning
> > of the entries from the namespace would be forbidden. unmount(2)
> > takes two strings as arguments, right? It doesn't even need an fd.
>
> because they're not visible.  you have to access
> it in order to unmount it.

I see what you meant now. For some reason, I constantly assume
that namespace is sort of a substitution table that helps you
walk(5) across the bind/mount points. But it is not. Is there
a simple reason for mandating access to the target of the bind?

Or here's an easier way to ask the same: is there a simple reason
for
   $ bind /foo /really/nested/bar
always triggering walks into /foo and /really/nested/bar and not
allowing for "lazy evaluation"?

Thanks,
Roman.

Re: [9fans] several things

[Yaroslav]

2008/10/18 Roman V. Shaposhnik <rvs@sun.com>:
> On Wed, 2008-10-15 at 08:17 -0400, erik quanstrom wrote:
>> > >   ; mntgen a
>> > >   ; bind /env a/env
>> > >   ; bind /bin a/bin
>> > >   ; bind /proc a/proc
>> > >   ; bind a /
>> > >   ; ns
>> > >
>> > > consider it a security feature.
>> >
>> > Be it as it may, I still can't quite follow why *manual* pruning
>> > of the entries from the namespace would be forbidden. unmount(2)
>> > takes two strings as arguments, right? It doesn't even need an fd.
>>
>> because they're not visible.  you have to access
>> it in order to unmount it.
>
> I see what you meant now. For some reason, I constantly assume
> that namespace is sort of a substitution table that helps you
> walk(5) across the bind/mount points. But it is not. Is there
> a simple reason for mandating access to the target of the bind?
>
> Or here's an easier way to ask the same: is there a simple reason
> for
>   $ bind /foo /really/nested/bar
> always triggering walks into /foo and /really/nested/bar and not
> allowing for "lazy evaluation"?

The evaluation of bind argument "happens at the time of the bind, not
when the binding is later used." -- see bind(2).
Also, /sys/doc/9.ps worth reading.

Re: [9fans] several things

[Roman V. Shaposhnik]

On Mon, 2008-10-20 at 17:09 +0300, Yaroslav wrote:
> > Or here's an easier way to ask the same: is there a simple reason
> > for
> >   $ bind /foo /really/nested/bar
> > always triggering walks into /foo and /really/nested/bar and not
> > allowing for "lazy evaluation"?
>
> The evaluation of bind argument "happens at the time of the bind, not
> when the binding is later used." -- see bind(2).

That is well understood. But perhaps you've misunderstood my question
(well, either that or I wasn't too articulate asking it). The question
was really about *why* such a behavior was chosen to begin with? On the
surface it seems that namespace-as-a-substitution table is not such
a bad idea AND it adds flexibility. After all, it is trivial to emulate
eager evaluation if you have lazy one implemented, but not the other
way around.

Of course, "you don't argue with Ken" (c) ;-) Which means that
there's a pretty good reason for bind evaluation to be eager, its just
that it doesn't seem obvious to me. Hence the question.

Thanks,
Roman.

Re: [9fans] several things

[Kernel Panic]

erik quanstrom wrote:
>>> Are these limitations listed in some document?
>>>
>> I don't believe they are.
>>
>> It might bve nice to think there are no arbitary limits in plan9
>> as the GNU mantra, however there are not many and personally,
>> working with remote servers with very long paths, I have never
>> (knowingly) hit this limit.
>>
>> Having said this we could probably afford to up the size of pwd's
>> buffer to, say, 8k to be sixteen times as sure.
>>
>
> if you're going to all that trouble, why not make sure?
> (i don't think this is worth it, personally, but if you do ...)
>
> #include <u.h>
> #include <libc.h>
>
> void
> main(void)
> {
> 	char *p;
> 	int n, s;
>
> 	for(s = 128; ; s <<= 1){
> 		p = malloc(s);
> 		if(p == nil)
> 			sysfatal("malloc");
> 		p[s-1] = 1;
> 		if((getwd(p, s)) == 0)
> 			sysfatal("pwd: %r");
> 		if(p[s-1] == 1)
> 			break;
> 	}
> 	print("%s\n", p);
> 	exits(0);
> }
>
> - erik
>
>
AAArgg!!!1111 We leak for a fraction of micro seconds! we should
do realloc() here of course and free() the memory before exits()
just to make it even more complex ;-)

cinap

Re: [9fans] several things

[erik quanstrom]

> > Are these limitations listed in some document?
>
> I don't believe they are.
>
> It might bve nice to think there are no arbitary limits in plan9
> as the GNU mantra, however there are not many and personally,
> working with remote servers with very long paths, I have never
> (knowingly) hit this limit.
>
> Having said this we could probably afford to up the size of pwd's
> buffer to, say, 8k to be sixteen times as sure.

if you're going to all that trouble, why not make sure?
(i don't think this is worth it, personally, but if you do ...)

#include <u.h>
#include <libc.h>

void
main(void)
{
	char *p;
	int n, s;

	for(s = 128; ; s <<= 1){
		p = malloc(s);
		if(p == nil)
			sysfatal("malloc");
		p[s-1] = 1;
		if((getwd(p, s)) == 0)
			sysfatal("pwd: %r");
		if(p[s-1] == 1)
			break;
	}
	print("%s\n", p);
	exits(0);
}

- erik

Re: [9fans] several things

[erik quanstrom]

 * This comment might belong somewhere else.

> > in the namespace (see the result of the 'ns' command; there you can
> > also spot that after issueing the 'mntgen' command a line
> > 'bind /usr/ruda/a /usr/ruda/a/' appears; that relates to my 4th
> > question; this bind is the one removed by the 'unmount' command).
> > How can I get rid of that then?
>
> Delete the namespace by closing the window.

i believe the answer to the original question is, you can't.

closing a window can delete a namespace, but there's more to the
story.  namespaces aren't tied to rio windows.  they're tied to processes.
(see rfork(2).)

namespaces are garbage collected.  when the last process / chan with a
reference to a namespace exits, the namespace is reclaimed.

deleting a rio window *can* be a special case of this.  (cf. the non-closing
rio window discussion.)

> You just found a bug; congratulations.

this is not a bug.  inaccessable bits are not pruned from
the namespace.  maybe that is  counter to your
expectations, but that doesn't make it a bug.

it would be a serious security problem if you could unbind
inaccessable bits from your namespace.  this would imply
you could access them.

- erik