cvs-nserver-devel

Re: [RFC Draft] ACL in CVS proposal

[<mo...@no...>]

I'd also like to introduce some comments/thoughts :-). Please see them
below.

08/17/2001 09:50:02 AM cvs-nserver-devel-admin wrote:
>* 99.99% of file permissions/ownership are the same in a directory.  My
>  patch does not have per-file permissions, and none of the users have
>  ever asked for it, and in our group we have never needed it.
I think it would be useful to separate different kinds of developers from
each other :-). Suppose you have 'core' programmers and front-end
designers. Programmers write javascripts that perform some essential
functionality on client  browser, designers write scripts to animate and
slow down interface as they love to do. Those scripts resides in a same
directory (or same directory hierarchy). Probably it would be useful to
separate 'scripts for programmers' and 'scripts for designers'. Another
example is the cvs-nserver sources itself where some files are shared
between client and server. Maybe Alex wishes to disallow some inaccurate
client writers from changing anything beyond their responsibility area :-)

>* 99% of permissions in a directory can be directly inherited from the
>  parent directory.
>
>* Development groups have a strong need for multiple users with
>  independent access controls.
>
>* Having groups of users that can be assigned permissions together (so
>  you only have to maintain per-directory permissions for the group,
>  not the individual users) is very helpful.
>
>* Per-branch tag permissions are useful, not only globally in the
>  repository, but also per-directory.  Designers use branch tags for
>  sandboxes and to let outsiders do work without affecting the main
>  branch, as well as having them for releases.
>
>* The concept of an owner is useful, because someone needs to maintain
>  the permissions, create branches for sandboxes, and someone needs to
>  have ultimate responsibility that is easily identifiable.  In a
>  large group, the administrators don't have the time nor the
>  knowledge to maintain permissions.
Should it be 'module administrators'? Or maybe it would be useful to add
another type of action on ACL: 'allow to modify ACL [for a particular
file/module/branch/etc]?'


>* You need the concept of a CVS administrator.
Should it be the only person or each module/branch etc can have its own
administrator?

Everything else looks quite reasonable for me.

Re: [RFC Draft] ACL in CVS proposal

[<mo...@no...>]

08/18/2001 02:02:28 AM minyard wrote:
>I'm copying the mailing list, since I assume you meant to send it
>there, too.
Ok, thanks. My comments are below.


>If it's the same directory hierarchy, then the different directories
>that house the different scripts can have different permission.  And
>I'm not against per-file permissions, I'm pointing out that it will be
>the exception, not the rule; keeping that in mind can simplify the
>design and improve the user interface.
Maybe you're right.

>> Should it be 'module administrators'? Or maybe it would be useful to add
>> another type of action on ACL: 'allow to modify ACL [for a particular
>> file/module/branch/etc]?'
>If you are saying that we should allow something more fine-grained
>(permission to make branches, permission to change ACLs), that's fine,
>I agree that it could be useful; better than a simple owner.
Yes, that's exactly what I mean. Yesterday we had an IRC session w/ Alex
Mahotkin (sorry, mostly in Russian :-/), generally he agreed to extend list
of actions that need to be ACLed and now he works on the new draft.

>> Should it be the only person or each module/branch etc can have its own
>> administrator?

>Someone needs access to the repository with the ability to do
>anything, and the verification needs to be done outside the normal ACL
>verification (so if the ACLs accidentally get deleted or set wrong,
>they can still work on the repository).
Well, do you think that should be a superuser inside CVS [repository] (on
per-repostitory basis)? Maybe we can just create several small maintainance
programs for system administrator (in fact it should be enough to run these
programs from within 'repository owner' system account) to perform rescue
actions (like ACL recreation etc). I think this would ease and decrease
amount of work needed.

>I have a separate admin file
>in the CVSROOT directory, anyone in that file can do anything to the
>repository as if they were the owner.

>I can ask some of the people that use my patch for input, or maybe we
>can allow them on the mailing list, or maybe we can come up with a
>strawman to run by the users to see what they think.
My company now performs a poll for our CVS admins, project managers and
team leaders on the subject. Probably we'll prepare a resuming document and
publish it here.

Re: [RFC Draft] ACL in CVS proposal

[<mi...@ac...>]

mo...@no... writes:

> >> Should it be 'module administrators'? Or maybe it would be useful to add
> >> another type of action on ACL: 'allow to modify ACL [for a particular
> >> file/module/branch/etc]?'
> >If you are saying that we should allow something more fine-grained
> >(permission to make branches, permission to change ACLs), that's fine,
> >I agree that it could be useful; better than a simple owner.
> Yes, that's exactly what I mean. Yesterday we had an IRC session w/ Alex
> Mahotkin (sorry, mostly in Russian :-/), generally he agreed to extend list
> of actions that need to be ACLed and now he works on the new draft.

I wish I spoke Russian, and I also wish I spoke many other languages :-(.

> 
> >> Should it be the only person or each module/branch etc can have its own
> >> administrator?
> 
> >Someone needs access to the repository with the ability to do
> >anything, and the verification needs to be done outside the normal ACL
> >verification (so if the ACLs accidentally get deleted or set wrong,
> >they can still work on the repository).
> Well, do you think that should be a superuser inside CVS [repository] (on
> per-repostitory basis)? Maybe we can just create several small maintainance
> programs for system administrator (in fact it should be enough to run these
> programs from within 'repository owner' system account) to perform rescue
> actions (like ACL recreation etc). I think this would ease and decrease
> amount of work needed.

It's actually quite easy to make an superuser type login in CVS, much
easier than writing independent programs.  When checking permissions,
just scan the admin file first and return "true" for any check if the
user is an admin.  I'm not sure about which would be more secure.  We
have administrators that I don't want to give access to the machine's
filesystem, but my situation is probably the exception, not the rule.

-Corey

Re: [RFC Draft] ACL in CVS proposal

[<mi...@ac...>]

I'm copying the mailing list, since I assume you meant to send it
there, too.

mo...@no... writes:

> I'd also like to introduce some comments/thoughts :-). Please see them
> below.
> 
> 08/17/2001 09:50:02 AM cvs-nserver-devel-admin wrote:
> >* 99.99% of file permissions/ownership are the same in a directory.  My
> >  patch does not have per-file permissions, and none of the users have
> >  ever asked for it, and in our group we have never needed it.
> I think it would be useful to separate different kinds of developers from
> each other :-). Suppose you have 'core' programmers and front-end
> designers. Programmers write javascripts that perform some essential
> functionality on client  browser, designers write scripts to animate and
> slow down interface as they love to do. Those scripts resides in a same
> directory (or same directory hierarchy). Probably it would be useful to
> separate 'scripts for programmers' and 'scripts for designers'. Another
> example is the cvs-nserver sources itself where some files are shared
> between client and server. Maybe Alex wishes to disallow some inaccurate
> client writers from changing anything beyond their responsibility area :-)

If it's the same directory hierarchy, then the different directories
that house the different scripts can have different permission.  And
I'm not against per-file permissions, I'm pointing out that it will be
the exception, not the rule; keeping that in mind can simplify the
design and improve the user interface.

> >
> >* The concept of an owner is useful, because someone needs to maintain
> >  the permissions, create branches for sandboxes, and someone needs to
> >  have ultimate responsibility that is easily identifiable.  In a
> >  large group, the administrators don't have the time nor the
> >  knowledge to maintain permissions.
> Should it be 'module administrators'? Or maybe it would be useful to add
> another type of action on ACL: 'allow to modify ACL [for a particular
> file/module/branch/etc]?'

If you are saying that we should allow something more fine-grained
(permission to make branches, permission to change ACLs), that's fine,
I agree that it could be useful; better than a simple owner.

> 
> >* You need the concept of a CVS administrator.
> Should it be the only person or each module/branch etc can have its own
> administrator?

Someone needs access to the repository with the ability to do
anything, and the verification needs to be done outside the normal ACL
verification (so if the ACLs accidentally get deleted or set wrong,
they can still work on the repository).  I have a separate admin file
in the CVSROOT directory, anyone in that file can do anything to the
repository as if they were the owner.

Good comments, we need to get a good discussion going.  I'm not saying
I am right here, I'm just voicing my experience.  It would be nice to
have some others with experience maintaining a repository for a group.
I can ask some of the people that use my patch for input, or maybe we
can allow them on the mailing list, or maybe we can come up with a
strawman to run by the users to see what they think.

-Corey

Re: [RFC Draft] ACL in CVS proposal

[<mi...@ac...>]

I'm resending this, because it may not have gone through the first
time.

mo...@no... writes:

> I'd also like to introduce some comments/thoughts :-). Please see them
> below.
> 
> 08/17/2001 09:50:02 AM cvs-nserver-devel-admin wrote:
> >* 99.99% of file permissions/ownership are the same in a directory.  My
> >  patch does not have per-file permissions, and none of the users have
> >  ever asked for it, and in our group we have never needed it.
> I think it would be useful to separate different kinds of developers from
> each other :-). Suppose you have 'core' programmers and front-end
> designers. Programmers write javascripts that perform some essential
> functionality on client  browser, designers write scripts to animate and
> slow down interface as they love to do. Those scripts resides in a same
> directory (or same directory hierarchy). Probably it would be useful to
> separate 'scripts for programmers' and 'scripts for designers'. Another
> example is the cvs-nserver sources itself where some files are shared
> between client and server. Maybe Alex wishes to disallow some inaccurate
> client writers from changing anything beyond their responsibility area :-)

If it's the same directory hierarchy, then the different directories
that house the different scripts can have different permission.  And
I'm not against per-file permissions, I'm pointing out that it will be
the exception, not the rule; keeping that in mind can simplify the
design and improve the user interface.

> >
> >* The concept of an owner is useful, because someone needs to maintain
> >  the permissions, create branches for sandboxes, and someone needs to
> >  have ultimate responsibility that is easily identifiable.  In a
> >  large group, the administrators don't have the time nor the
> >  knowledge to maintain permissions.
> Should it be 'module administrators'? Or maybe it would be useful to add
> another type of action on ACL: 'allow to modify ACL [for a particular
> file/module/branch/etc]?'

If you are saying that we should allow something more fine-grained
(permission to make branches, permission to change ACLs), that's fine,
I agree that it could be useful; better than a simple owner.

> 
> >* You need the concept of a CVS administrator.
> Should it be the only person or each module/branch etc can have its own
> administrator?

Someone needs access to the repository with the ability to do
anything, and the verification needs to be done outside the normal ACL
verification (so if the ACLs accidentally get deleted or set wrong,
they can still work on the repository).  I have a separate admin file
in the CVSROOT directory, anyone in that file can do anything to the
repository as if they were the owner.

Good comments, we need to get a good discussion going.  I'm not saying
I am right here, I'm just voicing my experience.  It would be nice to
have some others with experience maintaining a repository for a group.
I can ask some of the people that use my patch for input, or maybe we
can allow them on the mailing list, or maybe we can come up with a
strawman to run by the users to see what they think.

-Corey