Re: [9fans] bind -c[ab] -- what am I doing wrong?

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[northern snowfall]

>
>
>well, it doesn't. what you describe is the bahaviour of the command
>according to the  man page. but here's what I observe:
>
Yeh, and what is in the man page is what happens in usage:
but only in my examples. See, this is why I shouldn't get
to check mail until I've had my cranberry juice.

This is what really seems to happen:

The first directory bound into another forces the first
to inherit the second's creation properties. Thus, when we
bind a directory of ours onto a system file, we maintain
write access.

However, when a file that we do not have write access to
is bound into a directory we do have write access to, the
permissions inherited deny creation. This is your example,
Andrey. Though, we can easily remedy this situation by
binding a writable directory over the unwritable:
    cpu% bind -ac /sys/src/cmd try
    cpu% touch try/hello
    touch: try/hello: cannot create: access permission denied
    cpu% mkdir try2
    cpu% bind -ac try2 try
    cpu% touch try/hello
    touch: try/hello: cannot create: access permission denied
    cpu% unmount try2 try
    cpu% bind -bc try2 try
    cpu% touch try/hello
    cpu% wc -l try/unmount.c
         26 try/unmount.c
    cpu%

So the chain context persists, yet is not refinfluenced
by the preemptive bind. However, this doesn't change the
state of 'try'. Its permissions are still influenced by
the first bound directory. Our perception sees creation
is allowed, and that is all we technically care about.
Though, files are generated under the second bound
directory:
    cpu% unmount try
    cpu% ls -l try/hello
    ls: try/hello: 'try/hello' does not exist
    cpu% ls -l try2/hello
    --rw-rw-r-- M 2278 snowfall snowfall 0 Jul 17 13:49 try2/hello
    cpu%

Don

http://www.7f.no-ip.com/~north_

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[andrey mirtchovski]

On Thu, 17 Jul 2003, boyd, rounin wrote:

> you don't have PERMISSION -- read the message.
>

read my mail. i was EXPECTING to have permission.

as usual, those who knew what's happening explained it clearly enough, thanx
Dave.

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[boyd, rounin]

> plan9% bind -ac /sys kern
> plan9% touch kern/blah
> touch: kern/blah: cannot create: permission denied

you don't have PERMISSION -- read the message.

> plan9% touch tmp/blah

i creates a file called blah in tmp -- nothing to do with sys.

i'm going to stollys ...

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[northern snowfall]

>
>
>who's to blame?
>
You are! Binds make a list of directories like a linked
list chain. Our operations on these directories can always
be considered one of two primaries: read or write. Respectively,
we can think as the first link in the chain as the link we
Read from:
    cpu% cd
    cpu% mkdir testme
    cpu% cat > testme/u.h << EOF
        hello!
        EOF
    cpu% bind -bc testme /386/include
    cpu% wc -l /386/include/u.h
          1 /386/include/u.h
    cpu% cat /386/include/u.h
    hello!
    cpu% unmount /386/include

Or, we Read from the first bound directory that contains the
file we've requested access to. So, if 'testme' didn't contain
an u.h, the Read would return /386/include/u.h, despite testme
being bound 'before' /386/include/u.h.

Writes always take effect in the first directory we have permission
to write to in the chain. Most often this is the last link in the
chain:
    cpu% bind -ac testme /386/include/
    cpu% touch /386/include/foo
    cpu% ls -l testme/foo
    --rw-rw-r-- M 2265 snowfall snowfall 0 Jul 17 11:35 testme/foo
    cpu% unmount /386/include
    cpu%

So, if multiple directories we can write to were bound 'after'
our primary unwritable, we write to the first:
    cpu% bind -ac /tmp /386/include
    cpu% bind -ac testme /386/include
    cpu% touch /386/include/foo2
    cpu% ls -l /tmp/foo2
    --rw-rw-r-- M 2265 snowfall snowfall 0 Jul 17 11:38 /tmp/foo2
    cpu%

Hope that helps!
Don

http://www.7f.no-ip.com/~north_







>

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[David Presotto]

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

tmp is already a union directory (I'm assuming) so that the

	plan9% bind -ac /sys tmp

is binding a directory with create permissions behind a mount point
that already has a directory with create permissions.

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

From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] bind -c[ab] -- what am I doing wrong?
Date: Thu, 17 Jul 2003 11:34:25 -0600 (MDT)
Message-ID: <Pine.LNX.4.44.0307171132500.7478-100000@fbsd.cpsc.ucalgary.ca>

On Thu, 17 Jul 2003, boyd, rounin wrote:

> it's that easy.
>

how easy is that then:


 	plan9% ls -l | grep 'tmp|kern'
	d-rwxrwxr-x M 113 andrey andrey    0 Jul 17 10:53 kern
	d-rwxrwxr-x M 113 andrey andrey    0 Jul 17 11:32 tmp
	plan9% bind -ac /sys kern
	plan9% touch kern/blah
	touch: kern/blah: cannot create: permission denied
	plan9% bind -ac /sys tmp
	plan9% touch tmp/blah
	plan9%

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[David Presotto]

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

The confusing part may be the implicit bind that happens
when you do

	bind -ca /sys/src/cmd $home/kern/cmd

The resulting mount point has to things in the link
list bound there:

	/sys/src/cmd	- containing the create flag
	$home/kern/cmd	- not containing the create flag

The latter is implicit since you were binding -a onto a
directory.  You would have gotten the semantics you
wanted if you had said instead:

	bind -c $home/kern/cmd $home/kern/cmd
	bind -ca /sys/src/cmd $home/kern/cmd

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

From: "boyd, rounin" <boyd@insultant.net>
To: <9fans@cse.psu.edu>
Subject: Re: [9fans] bind -c[ab] -- what am I doing wrong?
Date: Thu, 17 Jul 2003 19:18:22 +0200
Message-ID: <00b901c34c87$6d509780$b9844051@insultant.net>

union directories are a linked list.

    - open finds you the first file in the list bound directories,
      in the order they were bound [before/after]

    - create choose the first directory which allows creation,
      in the order they were bound [before/after]

the order they were bound is not temporal, it's where you bind them.

it's that easy.

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[andrey mirtchovski]

On Thu, 17 Jul 2003, boyd, rounin wrote:

> it's that easy.
>

how easy is that then:


 	plan9% ls -l | grep 'tmp|kern'
	d-rwxrwxr-x M 113 andrey andrey    0 Jul 17 10:53 kern
	d-rwxrwxr-x M 113 andrey andrey    0 Jul 17 11:32 tmp
	plan9% bind -ac /sys kern
	plan9% touch kern/blah
	touch: kern/blah: cannot create: permission denied
	plan9% bind -ac /sys tmp
	plan9% touch tmp/blah
	plan9%

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[Richard C Bilson]

> From: andrey mirtchovski <mirtchov@cpsc.ucalgary.ca>
>
> given the man page i expect 'bind -ac new /something/i/can/write/to' to
> allow me to continue to write to '/something/i/can/write/to'.

Here's my guess.  To quote bind(1):

	When a new file is created in a union directory, it is placed
	in the first element of the union that has been bound or
	mounted with the -c flag. If that directory does not have write
	permission, the create fails.

In your example, you're creating a new union directory by binding "new"
with the -c flag.  The union has two directories, and only "new" has
been bound with -c.  If you don't have write permission to "new", the
create will fail.

One might expect some other result in the case where the second
argument is not already a union directory, but then again one might
expect the current behavior.

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[boyd, rounin]

union directories are a linked list.

    - open finds you the first file in the list bound directories,
      in the order they were bound [before/after]

    - create choose the first directory which allows creation,
      in the order they were bound [before/after]

the order they were bound is not temporal, it's where you bind them.

it's that easy.

Re: [9fans] bind -c[ab] -- what am I doing wrong?

[andrey mirtchovski]

On Thu, 17 Jul 2003, northern snowfall wrote:

>
> Hope that helps!
>

well, it doesn't. what you describe is the bahaviour of the command
according to the  man page. but here's what I observe:

	plan9% touch kern/test			# clearly I can write to it
	plan9% rm kern/test
	plan9% bind -ac /sys kern
	plan9% touch kern/test			# but not anymore
	touch: kern/test: cannot create: permission denied
	plan9%
	plan9% unmount kern
	plan9% bind -ac kern /sys
	plan9% touch /sys/blah			# this works as expected
	plan9%

given the man page i expect 'bind -ac new /something/i/can/write/to' to
allow me to continue to write to '/something/i/can/write/to'.

in fact, I expect to be able to write to '/something/i/can/write/to'
irregardless of whether it corresponds to 'new', 'old', is bound before or
bound after a directory. the only case when I wouldn't expect to be able to
write to it is when I'm not able to walk to it because of a bind -b earlier
in the walk.

in functional languages this technique is used as a formal proof of
a program's correctness, observe this example from the haskell prelude:

    -- Minimal complete definition: (==) or (/=)
    x == y      = not (x/=y)
    x /= y      = not (x==y)

a similar definition for 'bind' would be:

    bind -cb new old == bind -ca old new

where, of course, we consider only the resulting directory, and not the path
to it.

andrey

[9fans] bind -c[ab] -- what am I doing wrong?

[andrey mirtchovski]

It is my understanding that a bind() should be "commutative" with respect to
before/after, i.e.:

	bind -cb new old <==> bind -ca old new

why does the following create fail?

	plan9% bind -cb $home/kern/cmd /sys/src/cmd
	plan9% touch /sys/src/cmd/blah		# expected to succeed
	plan9% ls -l $home/kern/cmd/blah
	--rw-rw-r-- M 159 andrey andrey 0 Jul 17 10:06 /usr/andrey/kern/cmd/blah
	plan9% unmount /sys/src/cmd
	plan9% rm $home/kern/cmd/blah
	plan9% bind -ca /sys/src/cmd $home/kern/cmd
	plan9% touch $home/kern/cmd/blah	# expected to succeed
	touch: /usr/andrey/kern/cmd/blah: cannot create: permission denied
	plan9% touch /sys/src/cmd/blah		# expected to fail
	touch: /sys/src/cmd/blah: cannot create: permission denied
	plan9%

who's to blame?