RE: to stop commit

[Schrum, Allan (Allan)]

I concur. Mark's setup is nearly a mirror of ours. We have multiple
repositories that need controlled access. While UNIX group permissions could
address this at a gross level, it does not offer the same level of control
that readers / writers offers (the primary reason for using :pserver:
access).

In our environment, the repositories are owned by the "cvs" user so that the
users of CVS do not have direct access to the files. This was to avoid the
obvious temptation for people to directly change (or is it fix?) the
repository as well as avoid silly accidents caused by "rm". The :pserver:
mode provides a layer if disconnection from the repository that requires the
users to use the CVS tool. This abstraction helps preserve the integrity of
the repository as well as offering great flexibility.

If the failing of :pserver: is its security, then maybe we need a
:sshpserver: mode?

-Allan 

-----Original Message-----
From: Mark O'Brien [mailto:address@hidden
Sent: Friday, August 19, 2005 7:46 AM
To: info-cvs
Subject: Re: to stop commit


On 8/18/05, Mark D. Baushke <address@hidden> wrote:
>
> That said, there are pragmatic reasons why the CVS team has not tried to
> remove the :pserver: support from CVS. Many folks would not be able to
> get other enhancements and updates if we stopped supporting their
> current setup. I do wish we could remove support and strongly urge you
> to move away from :pserver: use if at all possible.

I actually would like to move away from pserver, however I would need
a setup for cvs ssh access that respects a readers and writers
concept. Where cvs can specify which users can read and write in which
repositories. If this happens, then all I would need is a cvs binary
that is wrapped to run as a common OS group.

Trying to maintain independent unix groups to manage read and write
access in each directory inside repository structures would be a
nightmare in our setup. Not just on the cvs side, but the user id
side. The pserver allows us to setup an individual passwd file for
each repo, which provides read access to that repo, and the writers
file which lists which passwd ids also have write access. No one has
unix access read/write to the cvs repository filesystem in our setup,
only the pserver account and the admin accout (only account permitt to
access via :local: method)

I don't completely subscribe to the rationale that controlling who can
perform what functions in within a toolset (such as cvs
checkout/commit) should be managed by OS file permissions inside a
code repository. The fact CVS's particular repository implementation
can somewhat do this by setting up OS file permission manually by hand
directly in the repository (which I think is a bad thing, personally
thinking nothing should be done outside of cvs commands to the cvs
repositories as a standard policy) does not give weight to that
arguement.

How have people implemented branch access controls in cvs? Via scripts
using ids, not by OS file permissions. How does the cvs admin
subcommand itselft control access to its functions, not by OS file
permissions, by an OS id (yes, a group id, on a tangent... but I this
it would be better to have admin access by OS id instead of OS group
and be able to setup lists per repo).

If you want to make pserver obsolete, you need to provide the
features/functions it provides to the access methods you would prefer
eveyone to use/move to.

Mark


_______________________________________________
Info-cvs mailing list
address@hidden
http://lists.nongnu.org/mailman/listinfo/info-cvs