cvs-nserver-devel — Developers

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...>]

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

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

[<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.

Updates

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

I finally won the battle against those fashionable GNU developemnt tools
and committed changes back to NCLI-1-11-1.

Changes:

src/rsh-client now fits Alex's specifications (but Alex please check it,
you're the only person who reached Zen at the moment :-)). I'm not sure it
works perfectly but it definitely compiles :-).

src/basic-fd-client provide simple unbuffered read/write to/from FD
(socket)

contrib/repcheck to be used as repository consistency checking tool.

Alex please tell me what versions of automake, libtool, autoconf etc are
"kosher" to be used in developemnt. I got numerous warnings that I don't
have automake of a correct version (I have 1.4, while 1.4a is needed);
'make' causes ./configure to re-run even if I successfully run it just
before make etc.

Re: [RFC Draft] ACL in CVS proposal

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

Having written a CVS ACL patch and used it extensively in a large
group, I have a few comments :-).

Some information from my experience:

* A version control system repository is like a filesystem, but does
  not map to a filesystem one-to-one.  Be careful making analogies
  to filesystems.

* 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.

* 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.

* You need the concept of a CVS administrator.

* Default file permissions are very important.


I have the following comments on my patch:

* Permissions are on a directory only.  There is an option to allow
  the permissions to be inherited from the parent directory (put in
  because so many people demanded it).  I was planning to add the
  ability to block the propigation, I think this would cover pretty
  much everything and be the most convenient way to do it.  If I
  wanted to add per-file permissions, I would by default take the
  directory permissions and let the user override them per-file.  This
  would drastically reduce the amount of ACL information that would
  need to be stored.

* I was planning on adding per-tag permissions.  With permissions
  being inherited, it would be very easy to grant per-tag permissions
  to the whole repository for a user or group.  This would solve the
  acl-per-file and acl-per-branch problem.

* I don't have the concept of default file permissions, and it has
  been a big problem.  With file permissions that propigate, though,
  it may not be a big deal.  My group cannot currently propigate file
  permissions (because that would give world-read access to the
  repository and we have a few things that we don't want world-read
  for), but with the ability to block the propigation it would be ok.

* Be careful to name your ACL control files something that is not
  likely to conflict with the name of a directory.  I didn't do this,
  and it has been a small problem.  It would probably be best to start
  it with a period.

* If you want to be able to track what is done in the main CVS
  release, you don't want the changes to change too much of the
  mainstream CVS code.  I didn't do this at first, and quickly
  switched.


I have some more comments inline below.  But this is a good start for
discussion, and I agree in principle with most of what you have said.

-Corey

Alexey Mahotkin <al...@hs...> writes:

> ACCESS CONTROL LISTS FOR CVS (Proposal)
> ========================================
> 
> This document discusses the design and implementation of ACL (Access
> Control Lists) for the cvs-nserver.
> 
> This document is open for comments, suggestions and modifications.  If
> you propose change large enough, please, provide a rationale for it.
> 
> You can commit new revisions of it into CVS after discussion in
> cvs-nserver-devel mailing list (available on
> http://sf.net/projects/cvs-nserver/).
> 
> The design of ACLs is based mostly on UNIX-style filesystem
> permissions, with additional list of specific privileges for each
> file.
> 
> 
> Primary Authorization Features
> ===============================
> 
> We need the following basic authorization features:
> 
> - the ACLs are assigned on per-branch, not on per-file basis. 
> 
>   Rationale: a very common task is "let support engineers commit
>   patches to the stable branch, and not to the trunk, which is for
>   main developers only";
> 
>   This should be considered from the very first days of development.
>   Maybe it would not be implemented right from the start, but
>   switching from "acl-per-file" to "acl-per-branch" would seem like
>   hell to do.
> 
> 
> - the basic operations that should be controlled for each branch are:
> 
> 	- check revision out;
> 
> 	  Rationale: don't let somebody see what happens on the
> 	  development branch.

Analagous to read access.

> 
> 	- check revision in;
> 
> 	  Rationale: obviously, don't let somebody commit anything on
> 	  this branch;

Analagous to write access.

> 
> 	- tag (non-branch) revisions (this includes moving and
> 	  deleting tags);

As long as it didn't apply to branch tags, I would make write access
allow tagging.

> 
> 	- create branches;
> 
> 	  Rationale: let the Release Manager do her job, don't let
> 	  mere developers to mark releases;

Remember that releases are not the only things that branches are used
for, they are also used for sandboxes, and other things, too.  I would
let the owner create branches.

> 
> 
> - the basic operations that should be controlled for each directory
>   are:
> 
> 	- accessing the files and subdirectories in this directories;
> 
> 	- modifying (checking in, tagging, creating branches, adding
> 	  and removing files, creating directories);
> 
>   Rationale: obviously, we need to handle simple and frequent cases:
>   "give somebody read-only access to the repository", "don't let
>   somebody access any files inside of a directory (with
>   subdirectories).
> 
> - newly created directories automatically get the same access rights
>   as their parent directory.
> 
>   Rationale: see the convenience of "BSD groups", see the abomination
>   of "set group of creating user".
> 
> - each directory could have default access rights for each branch that
>   are assigned to new files created within this directory on this
>   branch.  Those access rights are automatically inherited from
>   upper-level directories if needed.
> 
>   Rationale: obvious.  We somehow need a way to setup default
>   permissions to newly-created files; for flexibility this should be
>   done on a per-directory, per-branch basis.
> 
> 
> - when checking the access rights, the directories are traversed from
>   the top directory to the directory where the file resides;
> 
>   Rationale: obvious to anyone who has ever worked with filesystem
>   permissions :)
> 
> 
> - I don't think there is a need of concept for "owner" and "owner
>   group" for each file.
> 
>   Rationale: default permissions for files in any given directory
>   completely supersede the notions of owner/group.
> 
> 
> This list is probably not complete, though I think I've covered the
> essential parts.
> 
> 
> Quality Assurance
> ==================
> 
> I (or someone who is particularly interested) will soon create a set
> of tests for the proposed ACL semantics in the form of a .c-file with
> a simple, human-readable syntax (even though the actual code is not
> written yet, a-la Extreme Programming)
> 
> That way we'll have the tests ready when the actual code will be
> created, and the ACL semantics will be very clear from those tests.
> 
> Also, no new feature will be added without a test written for it
> first.  That way the usefulness of that feature could be proven, and
> no regression will occur because of it.

It would seem a lot easier to test the ACLs with a shell script.  We
could still write them ahead of time, and you will probably need some
program to act like a one-shot inetd to do the testing, but that
should be easy.  Shell script, or perl or something like that, will be
much easier to manage since they do the things we need to do much more
easily (execute commands and compare strings).

> 
> 
> Internal Structure
> ===================
> 
> I think that all ACL information should be stored into one single ACL
> file in each directory in the repository.  Probably it'll be later
> complemented with the corresponding ACL.db, for speed, but that's not
> an issue currently (we could always refactor later).
> 
> 
> --alexm
> 
> _______________________________________________
> Cvs-nserver-devel mailing list
> Cvs...@li...
> http://lists.sourceforge.net/lists/listinfo/cvs-nserver-devel

[RFC Draft] ACL in CVS proposal

[Alexey M. <al...@hs...>]

ACCESS CONTROL LISTS FOR CVS (Proposal)
========================================

This document discusses the design and implementation of ACL (Access
Control Lists) for the cvs-nserver.

This document is open for comments, suggestions and modifications.  If
you propose change large enough, please, provide a rationale for it.

You can commit new revisions of it into CVS after discussion in
cvs-nserver-devel mailing list (available on
http://sf.net/projects/cvs-nserver/).

The design of ACLs is based mostly on UNIX-style filesystem
permissions, with additional list of specific privileges for each
file.


Primary Authorization Features
===============================

We need the following basic authorization features:

- the ACLs are assigned on per-branch, not on per-file basis. 

  Rationale: a very common task is "let support engineers commit
  patches to the stable branch, and not to the trunk, which is for
  main developers only";

  This should be considered from the very first days of development.
  Maybe it would not be implemented right from the start, but
  switching from "acl-per-file" to "acl-per-branch" would seem like
  hell to do.


- the basic operations that should be controlled for each branch are:

	- check revision out;

	  Rationale: don't let somebody see what happens on the
	  development branch.

	- check revision in;

	  Rationale: obviously, don't let somebody commit anything on
	  this branch;

	- tag (non-branch) revisions (this includes moving and
	  deleting tags);

	- create branches;

	  Rationale: let the Release Manager do her job, don't let
	  mere developers to mark releases;


- the basic operations that should be controlled for each directory
  are:

	- accessing the files and subdirectories in this directories;

	- modifying (checking in, tagging, creating branches, adding
	  and removing files, creating directories);

  Rationale: obviously, we need to handle simple and frequent cases:
  "give somebody read-only access to the repository", "don't let
  somebody access any files inside of a directory (with
  subdirectories).

- newly created directories automatically get the same access rights
  as their parent directory.

  Rationale: see the convenience of "BSD groups", see the abomination
  of "set group of creating user".

- each directory could have default access rights for each branch that
  are assigned to new files created within this directory on this
  branch.  Those access rights are automatically inherited from
  upper-level directories if needed.

  Rationale: obvious.  We somehow need a way to setup default
  permissions to newly-created files; for flexibility this should be
  done on a per-directory, per-branch basis.


- when checking the access rights, the directories are traversed from
  the top directory to the directory where the file resides;

  Rationale: obvious to anyone who has ever worked with filesystem
  permissions :)


- I don't think there is a need of concept for "owner" and "owner
  group" for each file.

  Rationale: default permissions for files in any given directory
  completely supersede the notions of owner/group.


This list is probably not complete, though I think I've covered the
essential parts.


Quality Assurance
==================

I (or someone who is particularly interested) will soon create a set
of tests for the proposed ACL semantics in the form of a .c-file with
a simple, human-readable syntax (even though the actual code is not
written yet, a-la Extreme Programming)

That way we'll have the tests ready when the actual code will be
created, and the ACL semantics will be very clear from those tests.

Also, no new feature will be added without a test written for it
first.  That way the usefulness of that feature could be proven, and
no regression will occur because of it.


Internal Structure
===================

I think that all ACL information should be stored into one single ACL
file in each directory in the repository.  Probably it'll be later
complemented with the corresponding ACL.db, for speed, but that's not
an issue currently (we could always refactor later).


--alexm

socket-, logging-, and rsh-clients comply to checklist

[Alexey M. <al...@hs...>]

I've updated the client.c, socket-client.[ch], logging-client.[ch],
and rsh-client.[ch] (Alex, don't worry, this one was modified very
slightly), and client_pserver_auth.c so that the clients match the
checklist inside of ncli-architecture.txt, and their callers match
their interface.


Hmm, I think I'll create cvs-nserver-commits mailing list for that
kind of stuff (and it will be handled by SF's CVS automatically).

--alexm

[Cvs-nserver-devel] repository appeared on SourceForge!

[Alexey M. <al...@hs...>]

Hello,

without warning, the repository is online.  Brief instructions (to
save you time of reading the F.A.Q. :)

1) ssh you...@cv...  (it won't let you do anything,
   just will create your homedir on cvs machine);

2) export CVS_RSH=ssh  (ssh version 1 required);

3) cvs -z3 -d :ext:you...@cv...:/cvsroot/cvs-nserver co \
	-r NCLI-1-11-1 cvs-nserver

3.5) if you need stable cvs-nserver for some reason (don't commit
     there without my blessing, please), replace "-r NCLI-1-11-1" with
     "-r NSERVER-1-11-1"

4) Here you are.  

--alexm


P.S.: alex, I assume that you'll subscribe to -devel right away.  I
give you 24 hours for that :)