[9fans] group organization

[9fans] group organization

[G.David]

From: Kenji Arisawa <arisawa@vega.aichi-u.ac.jp>
>
>Hello 9fans!
[snip]
>
>Plan9 forbids:
>    chgrp group file ...
>to the group the user does not belong to.
>I cannot understand this restriction.
>What problem does it make if plan9 admits:
>    chgrp anygroup file ...

It is similar to "chown anyuser file ..."  If you don't have
a problem with that one, then you won't have one with yours.

I think the goal is that the ownership (or "groupship") of
files needs to be "trusted".

>Here is an example that shows this effect.
>Let /adm/users be
>    alice:alice
>    bob:bob:
>    david:david:
>and david be a professional programmer who is advising both alice and bob.
>Assume alice doesn't want to be read her file to bob and
>bob also doesn't want to be read his file to alice.
>
>Then if alice and bob could execute respectively,
>    alice% chgrp david herfile; chmod 640 herfile
>    bob% chgrp david hisfile; chmod 640 hisfile
>everything would go well!

How about let /adm/users be
	alice:alice:david
	bob:bob:david
	david:david:

Then alice and bob only have to chmod g+r theirfile

[9fans] group organization

[G.David]

From: schwartz+9fans@finch.cse.psu.edu (Scott Schwartz)
>"G. David Butler" <gdb@dbSystems.com> writes:
>| Unless you have a large user population with multiple domains of
>| administration
>
>Welcome to *.edu.

Amen!

>| the group concept is simpler and sufficient.
>
>It's simpler to code, but not simpler to use.
[snip]
>Worse, if you really use that scheme, you can end up with an
>unsightly number of such groups.

True, that is why I said it is just a "macro".

>|I would like to see an efficient ACL implementation to consider.
Let me say that another way.  I have done many *major* changes to
the system without sacrificing the API.  I have proposed a few that
change that and much more.  I too like ACL's, but I don't have the
time to design it into the system.  (it is not critical to my
intended use.)  Design it, without touching the API, or extending
it in a backward compatible way, and you may get your wish...

David Butler
gdb@dbSystems.com

[9fans] group organization

[Scott]

"G. David Butler" <gdb@dbSystems.com> writes:
| Unless you have a large user population with multiple domains of
| administration

Welcome to *.edu.

| the group concept is simpler and sufficient.

It's simpler to code, but not simpler to use.

My experience is that in small organizations, everything is world
readable, owner writable, and there's one big group that everyone
(except for e.g. uucp) is in so you can have almost-world-writable
directories.  ACLs are much nicer.

| (A group is just a ACL "macro".)

I disagree.  Under that regime, in order to give a person new access to
a file, you have to create a new group, dragging the authentication
server into the picture every time you want to adjust some file.
Worse, if you really use that scheme, you can end up with an
unsightly number of such groups.

[9fans] group organization

[G.David]

From: Scott Schwartz <schwartz@finch.cse.psu.edu>
>
>I hate to raise heretical notions, but I really don't think
>user/group/other works very often, and it's not worth trying to tweak
>it.  If a filesystem object isn't world readable, then 90% of the time
>I want an access control list (maybe just for directories) to specify
>who gets to do what with that file.  Allowing the authentication
>system to put users in multiple catagories, even if you can change
>them easily, doesn't seem to me to be the right solution.

I would like to see an efficient ACL implementation to consider.

Unless you have a large user population with multiple domains of
administration the group concept is simpler and sufficient.  (A
group is just a ACL "macro".)  For my part, I like the tighter
security of P9 over *NIX.  If you have followed the list you will
notice I have tightened it further.  (I have effectively excluded
"none" from "other".)

>"If I want Multics, I know where to find it."
Yes, but is it available in source and does it run on a PC? :->

[9fans] group organization

[Scott]

I hate to raise heretical notions, but I really don't think
user/group/other works very often, and it's not worth trying to tweak
it.  If a filesystem object isn't world readable, then 90% of the time
I want an access control list (maybe just for directories) to specify
who gets to do what with that file.  Allowing the authentication
system to put users in multiple catagories, even if you can change
them easily, doesn't seem to me to be the right solution.

"If I want Multics, I know where to find it."

[9fans] group organization

[Kenji]

Hello 9fans!

>From: David Butler <gdb@dbSystems.com>

>I've been thinking of how to allow network access to the file server
>besides the "connect a serial cable to a cpu server and use consolefs".
>Perhaps a file like /adm/cons which provides read/write access to the
>console thread.  Then you put users in the adm group with read/write
>group perms on /adm/cons to get to it.  Comments?

That may be a good idea. I will try it.

By the way, I have another question on the group organization.
Plan9 forbids:
    chgrp group file ...
to the group the user does not belong to.
I cannot understand this restriction.
What problem does it make if plan9 admits:
    chgrp anygroup file ...

Here is an example that shows this effect.
Let /adm/users be
    alice:alice
    bob:bob:
    david:david:
and david be a professional programmer who is advising both alice and bob.
Assume alice doesn't want to be read her file to bob and
bob also doesn't want to be read his file to alice.
Then if alice and bob could execute respectively,
    alice% chgrp david herfile; chmod 640 herfile
    bob% chgrp david hisfile; chmod 640 hisfile
everything would go well!


Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp

[9fans] group organization

[G.David]

From: Kenji Arisawa <arisawa@vega.aichi-u.ac.jp>

>But I cannot find a user command to add group members.
>If a user can organize his own group, it must be wonderful.

The user can use the command "mail" to add users to his group. :-)

The mail is sent to the person that can lay hands on the fileserver
to type "newuser group +new_member".  Even if there are members
of the adm group with write permission on /adm/users, unless someone
types at the fileserver "users", it won't take till a reboot.

Yet another example where Plan9 security works.

This stuff is not necessary to change a password at least.  That
info is managed from the auth server which has a network interface.

I've been thinking of how to allow network access to the file server
besides the "connect a serial cable to a cpu server and use consolefs".
Perhaps a file like /adm/cons which provides read/write access to the
console thread.  Then you put users in the adm group with read/write
group perms on /adm/cons to get to it.  Comments?

David Butler
gdb@dbSystems.com

[9fans] group organization

[Kenji]

Hello 9fans!

I have a question on the group organization of users.
In the document "Plan 9 from Bell Labs", you will find:

>	pjw:pjw:
>	sys::pjw,ken,philw,presotto
>The first ...
>In our example, only pjw can add members to his group, but ...

But I cannot find a user command to add group members.
If a user can organize his own group, it must be wonderful.

Kenji Arisawa
E-mail: arisawa@aichi-u.ac.jp