[9fans] group permission

[9fans] group permission

[arisawa]

A question on group permission.

I have long been feeling an inconvenience about a group permission.
Suppose a user alice has a private file "foo" that she want to be
read by bob.
She cannot
	chgrp bob foo
because she is not a member of bob.
Thus she must ask her host owner to create a group so that both alice
and bob be members of the group.
Is this inconvenient?
If host owner is in travel, she must wait until host owner comes back!

Is there any problem if alice can
	chgrp bob foo
even if she is not a member of bob?

Kenji Arisawa

Re: [9fans] group permission

[Sascha Retzki]

> Is there any problem if alice can
> 	chgrp bob foo
> even if she is not a member of bob?
>


On unix you got +s-bits, so a cool way for a rootshell is to setuid a copy of /bin/sh and make a nice present to Mr. root ;) - Plan9 got neither root nor +s, so I don't see a problem.


(Of course, you must be the owner of that file to make chgrp, elsewise, the model breaks.)

> Kenji Arisawa

Re: [9fans] group permission

[Skip Tavakkolian]

> Suppose a user alice has a private file "foo" that she want to be
> read by bob.
> She cannot
> 	chgrp bob foo
> because she is not a member of bob.

this works for me:

alice% srvfs 4bob /usr/alice/4bob
alice% chmod 666 /srv/4bob

then, bob

bob% mount /srv/4bob /n/fromalice

Re: [9fans] group permission

[csant]

> alice% srvfs 4bob /usr/alice/4bob
> alice% chmod 666 /srv/4bob
>
> then, bob
>
> bob% mount /srv/4bob /n/fromalice

will fred be able to see these files as well? or are they only for bob?
/c

Re: [9fans] group permission

[Russ Cox]

This isn't limited to just this one case.
According to the documentation, a group owner
has the ability to add or remove people from a group,
but actually there is no interface for doing so.

The right solution is probably a way to talk to a file
server to create a new group (owned by the
user who created it) and also to edit existing groups,
subject to the documented permissions.

Russ

Re: [9fans] group permission

[arisawa]

Russ's solution solves most popular case that arises in human group
working.
However allowing chgrp without editing /adm/users will solve
different problem.
Suppose bob is a teacher and he is teaching something to alice and
carol.
Alice want to show her files to only bob, and carol also want to show
her files only to bob.
How to do that ?
Creating new group does not answer the purpose.
The only solution of current Plan 9 is
	chgrp bob ...
by host owner.

My question comes from real problem.
bob is a service program.
alice and carol are system users.

Kenji Arisawa

On 2006/07/31, at 4:39, Russ Cox wrote:

> This isn't limited to just this one case.
> According to the documentation, a group owner
> has the ability to add or remove people from a group,
> but actually there is no interface for doing so.
>
> The right solution is probably a way to talk to a file
> server to create a new group (owned by the
> user who created it) and also to edit existing groups,
> subject to the documented permissions.
>
> Russ

Re: [9fans] group permission

[Russ Cox]

          other defined permission and mode bits can.  The gid can be
          changed: by the owner if also a member of the new group; or
          by the group leader of the file's current group if also
          leader of the new group (see intro(9P) for more information
          about permissions, users, and groups).  None of the other

I don't think anything terrible would happen if
one deleted the text "if also a member of the new group"
for the owner.  Maybe it's a holdover from Unix worth
getting rid of.  It's almost certainly a one-line change
to fossil.

Russ

Re: Re: [9fans] group permission

[Rob Pike]

Nothing terrible might happen but the current design is a
well-considered choice.  I'd like to be won over by a technical
argument before sanctioning a change.

-rob

On 7/30/06, Russ Cox <rsc@swtch.com> wrote:
>           other defined permission and mode bits can.  The gid can be
>           changed: by the owner if also a member of the new group; or
>           by the group leader of the file's current group if also
>           leader of the new group (see intro(9P) for more information
>           about permissions, users, and groups).  None of the other
>
> I don't think anything terrible would happen if
> one deleted the text "if also a member of the new group"
> for the owner.  Maybe it's a holdover from Unix worth
> getting rid of.  It's almost certainly a one-line change
> to fossil.
>
> Russ
>

Re: [9fans] group permission

[Skip Tavakkolian]

*if* /srv handled group permissions some of these use cases could be
done through /srv, couldn't it?

an old discussion where pressoto and nemo outlined the problem:
(btw, has pressoto disowned 9fans?)

http://groups.google.com/group/comp.os.plan9/browse_thread/thread/846148c4df8ea674/9fe6dabdb7a7edb4?lnk=gst&q=group+permissions+on+%2Fsrv&rnum=1#9fe6dabdb7a7edb4

>           other defined permission and mode bits can.  The gid can be
>           changed: by the owner if also a member of the new group; or
>           by the group leader of the file's current group if also
>           leader of the new group (see intro(9P) for more information
>           about permissions, users, and groups).  None of the other
>
> I don't think anything terrible would happen if
> one deleted the text "if also a member of the new group"
> for the owner.  Maybe it's a holdover from Unix worth
> getting rid of.  It's almost certainly a one-line change
> to fossil.

Re: [9fans] group permission

[Russ Cox]

> Russ's solution solves most popular case that arises in human group
> working.
> However allowing chgrp without editing /adm/users will solve
> different problem.
> Suppose bob is a teacher and he is teaching something to alice and
> carol.
> Alice want to show her files to only bob, and carol also want to show
> her files only to bob.
> How to do that ?
> Creating new group does not answer the purpose.
> The only solution of current Plan 9 is
>         chgrp bob ...
> by host owner.

There is another solution.

Bob can create a directory, say /bob/submit,
and make it group bob and mode 777.
Then alice and carol can each run
    mkdir /bob/submit/$user
    chmod 770 /bob/submit/$user
and put their files in that new directory,
which is owned by them but has group bob.

Russ

Re: [9fans] group permission

[arisawa]

On 2006/07/31, at 23:37, Russ Cox wrote:
>
> There is another solution.
>
> Bob can create a directory, say /bob/submit,
> and make it group bob and mode 777.
> Then alice and carol can each run
>    mkdir /bob/submit/$user
>    chmod 770 /bob/submit/$user
> and put their files in that new directory,
> which is owned by them but has group bob.
>
> Russ

I have understood well that the word "only" should be used carefully.
My example was too simple one.

Re: [9fans] group permission

[Victor Nazarov]

arisawa@ar.aichi-u.ac.jp wrote:

> Russ's solution solves most popular case that arises in human group
> working.
> However allowing chgrp without editing /adm/users will solve
> different problem.
> Suppose bob is a teacher and he is teaching something to alice and
> carol.
> Alice want to show her files to only bob, and carol also want to show
> her files only to bob.
> How to do that ?
> Creating new group does not answer the purpose.
> The only solution of current Plan 9 is
>     chgrp bob ...
> by host owner.
>
> My question comes from real problem.
> bob is a service program.
> alice and carol are system users.

I think alice and carol should create two different groups and add bob
to these groups. IMHO, allowing regular users to create groups is
essensial in multiuser environment. I don't know what's the problem is,
but it's better then ACLs.
--
Victor

Re: [9fans] group permission

[Wes Kussmaul]

Victor Nazarov wrote:
> arisawa@ar.aichi-u.ac.jp wrote:
>> Suppose bob is a teacher and he is teaching something to alice and 
>> carol.
>> Alice want to show her files to only bob, and carol also want to show 
>> her files only to bob.
>> How to do that ?
> I think alice and carol should create two different groups and add bob 
> to these groups. IMHO, allowing regular users to create groups is 
> essensial in multiuser environment. I don't know what's the problem 
> is, but it's better then ACLs.
This is an example of a correct technical solution to a problem that 
works only in the rare situation where users' main focus of attention is 
the management of their online resources, e.g. all are software engineers.

For the rest of the world, collaboration facilities must be managed as 
offices are managed. The ACL is analogous to the list of individuals who 
have keys to a particular facility. In this situation the teacher needs 
to own and control the drop slot, a "device" within the office to which 
he/she controls the ACL and into which users can place files that can 
only be read by the owner/manager of the room. Relying upon users to 
create and manage groups for this kind of thing is not realistic.

-- 
Wes Kussmaul
CIO
The Village Group
738 Main Street
Waltham, MA 02451
USA

781-647-7178


My uncle likes to say that the world’s biggest troubles started when the serpent said, “Try this fruit, and by the way if a bunch of people collectively calling themselves Arthur Andersen signs something it’s the same as if a person named Arthur Andersen signed it.” I don’t get the serpent and fruit part. Must be some Swiss mythology thing. He can be a bit obscure. 

                         P.K. Iggy
                         _How I Like Fixed The Internet_
                           (Tales from the Great Infodepression of 2009
                           and the prosperity that followed)

Re: [9fans] group permission

[Sascha Retzki]

Got a nice collection...

> For the rest of the world, collaboration facilities must be managed as
> offices are managed. The ACL is analogous to the list of individuals who
> have keys to a particular facility. In this situation the teacher needs
> to own and control the drop slot, a "device" within the office to which
> he/she controls the ACL and into which users can place files that can
> only be read by the owner/manager of the room. Relying upon users to
> create and manage groups for this kind of thing is not realistic.

I think the 'group owner' is the one you are looking for. Besides chgrp allowed  for regular users, I still think the group-owner-thing rocks and it should be there. (I actually just read about 'group owners' once, loved the idea, and expected the tools to exist.. they don't? :((    )

> There is another solution.
>
> Bob can create a directory, say /bob/submit,
> and make it group bob and mode 777.
> Then alice and carol can each run
>     mkdir /bob/submit/$user
>     chmod 770 /bob/submit/$user
> and put their files in that new directory,
> which is owned by them but has group bob.

I don't think that is a solution - but a nice workarround ;)

(Not to think about explaining two pupils, office clerks, $whatever for the millionth time how that actually works)


> Nothing terrible might happen but the current design is a
> well-considered choice.  I'd like to be won over by a technical
> argument before sanctioning a change.


I think creating a real interface instead of making the users use 'tricks' is simply the right thing. At least to a certain degree.

Yes I agree, that 'degree' may be something different to you ;)

If that does not satisfy you:
	Maybe that sounds stupid, but what is a 'technical' argument then?


>  Maybe it's a holdover from Unix worth
> getting rid of.  It's almost certainly a one-line change
> to fossil.

great. :)


> The right solution is probably a way to talk to a file
> server to create a new group (owned by the
> user who created it) and also to edit existing groups,
> subject to the documented permissions.


Sorry, one last thing: There must be an intermediet step that I miss, why create new groups (is that a DoS? Create new groups in a for-loop, named pretty much the same, to make maintaince-time extra expensive?)?


Mfg, Sascha