[9fans] Plan9 permissions

[9fans] Plan9 permissions

[rsc]

	lucio@proxima.alt.za writes:

	description of permissions, and it seemed equally silly.  But in 
	practice the owner may prefer to be reminded not to alter the contents 
	of a file that a log process is allowed to update.

i don't know.  that implies that the log process is not
running as you, i.e. is running as none or another user, like "upas".
if another user, then make that user the owner of the file.
if "none", think strongly about the append-only flag.
the editors warn about that, and it encourages others not
to edit the file either.

russ

[9fans] Plan9 permissions

[G.David]

From: rsc@plan9.bell-labs.com
>
>	gdb wrote:
>
>	Take for example the incoming directory for anonymous ftp,
>	/usr/none/incoming.
>
>There is a way to handle incoming directories for
>anon ftp working within the current permissions scheme, and it

[deleted yet another example of plan9's benefits over other OSs]

From: Lucio de Re <lucio@proxima.alt.za>
>
>Note, as David says, that the more obvious approach has no mechanism to 
>stop the owner doing anything if anyone else can do it.  In such a 
>situation, a 446 permission serves no useful purpose.

I guess it comes down to that.  From the file owner's point of view
what is the difference from 777, 077 (assuming owner is in file's
group) or 007 and from the group's point of view of 077 and 007?
It would seem you are throwing away access granularity for no good reason.

[9fans] Plan9 permissions

[rsc]

	gdb wrote:

	Take for example the incoming directory for anonymous ftp,
	/usr/none/incoming.

There is a way to handle incoming directories for
anon ftp working within the current permissions scheme, and it
is (tersely) illustrated on the CD.  (Basically, we want to be able
to drop files off in /incoming but don't want the outside world to be
able to read them).

You can create a directory in incoming for each user,
and set the permissions appropriately:

	d-rwxrwx-wx rsc rsc /usr/none/incoming/rsc

Or you can just create a directory in incoming named for each
user (but with any permissions, ownership you want) and bind
the directory /usr/$user/incoming onto it, as was done in 
/lib/namespace.ftp on the CD:

	bind -c /usr/andrew/incoming /usr/none/incoming/andrew

This has a few benefits.  The first is that each user has h^(is er)
own incoming directory and thus the namespace collisions go 
down tremendously (most users know when they are expecting files,
especially files named "foo" or "bar").  

Another advantage is that each user can turn on or off,
quite easily, whether or not they
are expecting files.  Just "chmod o-wx incoming".  By
having this on only when expecting files, you reduce the chance of
someone maliciously filling your disk with garbage.
If you were really paranoid, you could "chmod -r /usr/none/incoming"
and then people would have to know which directory to be in
to drop off files.

Third, if you don't want the world seeing whatever file
is being dropped off, you might not (at least on a large server
installation) want other users of the system seeing it either.
This takes care of that as well.

Fourth, if you want to leave a file for someone else, then you
can simply create one in your incoming directory and chmod it
"o+r" and then if they know the name, they can still read it.

You've got all the functionality of the traditional ftp
/incoming directories as well as easy user control of personal
incoming directories.

Russ

ps. ignore my from address; i speak with less authority
(and perhaps common sense) than anyone else on this list.

[9fans] Plan9 permissions

[G.David]

From: Lucio de Re <lucio@proxima.alt.za>

>From the BSD man pages:

I tried carefully not to use the *NIX description here since
Plan9 is NOT *NIX.  I don't want to start a trend :-)

[9fans] Plan9 permissions

[Lucio]

> 
> i don't know.  that implies that the log process is not
> running as you, i.e. is running as none or another user, like "upas".
> if another user, then make that user the owner of the file.
> if "none", think strongly about the append-only flag.
> the editors warn about that, and it encourages others not
> to edit the file either.
> 
Russ,

you're missing a point here.  On the one hand, quite correctly, the 
owner has one "permission" bit no-one else can alter, namely ownership.

On the other, making group and other inclusive does not gain you 
anything, it is better to make them exclusive, as Unix does, so that 
you can stop the owner from accessing something while allowing 
arbitrary users, than to have no means whatsoever to achieve this 
objective.

There's nothing compulsory about it, nobody has to use the permissions 
in this fashion, but removing the facility by opting for the 
intuitively obvious approach, decreases the flexibility of the tool.

>From the BSD man pages:

     [EACCES]      Permission bits of the file mode do not permit the request-
                   ed access, or search permission is denied on a component of
                   the path prefix.  The owner of a file has permission
                   checked with respect to the ``owner'' read, write, and exe-
                   cute mode bits, members of the file's group other than the
                   owner have permission checked with respect to the ``group''
                   mode bits, and all others have permissions checked with re-
                   spect to the ``other'' mode bits.

Note the "members of the file's group _other_than_the_owner_" and the 
implicit similar exception in the "other".  This reads precisely as 
David would have it.
-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.

[9fans] Plan9 permissions

[G.David]

From: rsc@plan9.bell-labs.com
>	I think the paragraph should read:
>
>	"When the owner attempts to do something to a file, the owner
>	permissions are consulted only, and if they grant the requested
>	permission, the operation is allowed.  For someone who is not the
>	owner, but is a member of the files's group, only the group
>	permissions are consulted.  The other permissions are only used
>	if the requestor is not the owner or a member of the file's group."
>
>but then it wouldn't be true.

You could have assumed the following:

int
iaccess(File *f, Dentry *d, int m)
{
	/*
	 * various forms of superuser
	 */
	if(writeallow)
		return 0;
	if(wstatallow && d->mode & DDIR)
		return 0;
	if(duallow && duallow == f->uid &&
	  d->mode & DDIR && (m == DREAD || m == DEXEC))
		return 0;
	/*
	 * owner is next
	 */
	if(f->uid == d->uid) {
		if(m << 6 & d->mode)
			return 0;
		else
			return 1;
	}
	/*
	 * group membership is hard
	 */
	if(ingroup(f->uid, d->gid)) {
		if(m << 3 & d->mode)
			return 0;
		else
			return 1;
	}
	/*
	 * other is easiest
	 */
	if(m & d->mode)
		return 0;
	else
		return 1;
}

Take for example the incoming directory for anonymous ftp,
/usr/none/incoming.

My way it can be:

d--wxrwxr-x M X none none

Your way it has to be:

d--wx-wx-wx M X none none (you have to change perms to see contents)
	or
d--wxrwx-wx M X none sys (or something not none)

>it is silly to honor permissions that are not
>monotonically nonincreasing (octal digitwise)
>from owner to everyone.

Huh?

>if you are the owner and the permissions are
>something like 466, then you can just change them
>with chmod.  if you are in the group and the 
>permissions are something like 446 or 646, then
>you can just become none (echo -n none >/dev/user)
>and then you have permission again.

So, you are the owner.

>look at /sys/src/fs/port/sub.c:/^iaccess
>on the cd.

Things Change.

[9fans] Plan9 permissions

[Lucio]

> 
> if you are the owner and the permissions are
> something like 466, then you can just change them
> with chmod.  if you are in the group and the 
> permissions are something like 446 or 646, then
> you can just become none (echo -n none >/dev/user)
> and then you have permission again.
> 
And yet, David has a point.  I remember my first confrontation with the 
description of permissions, and it seemed equally silly.  But in 
practice the owner may prefer to be reminded not to alter the contents 
of a file that a log process is allowed to update.

Note, as David says, that the more obvious approach has no mechanism to 
stop the owner doing anything if anyone else can do it.  In such a 
situation, a 446 permission serves no useful purpose.

-- 
Lucio de Re (lucio@proxima.alt.za)
Disclaimer: I'm working at getting my opinions to agree with me.

[9fans] Plan9 permissions

[rsc]

	I think the paragraph should read:

	"When the owner attempts to do something to a file, the owner
	permissions are consulted only, and if they grant the requested
	permission, the operation is allowed.  For someone who is not the
	owner, but is a member of the files's group, only the group
	permissions are consulted.  The other permissions are only used
	if the requestor is not the owner or a member of the file's group."

but then it wouldn't be true.

it is silly to honor permissions that are not
monotonically nonincreasing (octal digitwise)
from owner to everyone.

if you are the owner and the permissions are
something like 466, then you can just change them
with chmod.  if you are in the group and the 
permissions are something like 446 or 646, then
you can just become none (echo -n none >/dev/user)
and then you have permission again.

look at /sys/src/fs/port/sub.c:/^iaccess
on the cd.

russ

[9fans] Plan9 permissions

[G.David]

Intro(5) second to last pargraph says:

"When the owner attempts to do something to a file, the owner, group
and other permissions are consulted, and if any of them grant the
requested permission, the operation is allowed.  For someone who is
not the owner, but is a member of the file's group, the group and
other permissions are consulted.  For everyone else, the other
permissions are used."

This means that to deny the owner write permission you must deny
everyone (unless the owner is not a member of the file's group).

I think the paragraph should read:

"When the owner attempts to do something to a file, the owner
permissions are consulted only, and if they grant the requested
permission, the operation is allowed.  For someone who is not the
owner, but is a member of the files's group, only the group
permissions are consulted.  The other permissions are only used
if the requestor is not the owner or a member of the file's group."

Comments?

David Butler
gdb@dbSystems.com