Re: CVS access control

[yap_noel]

>address@hidden - Wed at 01:23:12PM -0400]
>> >The pserver method is, as for now, the only one that can offer any real
>> >access controls.  As I understood, cvs users could only access the box
in
>> >question through cvs.
>>
>> I see nothing wrong with SSH.  Also, from what I've heard, pserver is
not
>> secure.
>
>I think we're miscommunicating a bit.
>
>If we rely on the file system for all the access control, SSH is perfect!

I think you're confusing authorization with authentication.  SSH is perfect
for authentication.  It does not do authorization (short of minimally
controlling what set of commands you're allowed to execute).

>The original poster had a need for _additional_ access control.  I can see
>three quite so good reasons why it might be needed:
>
>1. As the original posters problem: Because it was not given by the OS
(what
>a crappy OS!).

Then get a file system that's POSIX compliant.  An alternative is to have
multiple groups and manage the permissions within the repo.

>2. A user that can modify the ,v-files directly, can make a lot of harm -
>including falsify old versions and corrupting the files.  You can't do any
>irreversial harm (at least it shouldn't be possible) through CVS.

This can be controlled through SSH (judging from your email I think you
already know how).  An alternative is to use a setgid cvs executable and
file system permissioning.

>3. We might want to grant a user to commit only to a specific branch.

Would said user be able to redefine branches?  If so, then such ACLs are
useless from a security POV.

>_If_ CVS was to support access control (i.e. the way the original poster
>wanted to do it), there are two ways to enforce people to go through the
CVS
>access control:
>
>1. Disallowing cvs users to log into the server.  (pserver, or the
>sourceforge solution - using ssh, but only allowing users to use cvs)

I prefer SSH since SSH was designed with security in mind.

>2. setuid'ness/setgid'ness - disallowing people to modify anything under
>$CVSROOT, except through the CVS tool.

And how do you control who is allowed to execute the setgid cvs?

>Of course, in a perfect world, access control wouldn't be needed at all,
>because we trust each other, all right? :-)

You can't really trust someone if they haven't been properly authenticated.

>> I've tried this (on an experimental basis) and had no problems
whatsoever.
>
>Probably not.  Anyway, my manual does at least state that it's not
>constructed for it.  For all I know, there might be a myriad of small
>security holes - haven't studied the source, so I can't tell.  Of course,
>you wouldn't notice them until it's too late - and probably even not then.

If you're that worried about security, don't use pserver.  In fact, don't
use CVS for security-related stuff (eg authentication or authorization).

>> But then, how do you control who is able to execute this setgid (I
wouldn't
>> use setuid) cvs?  I used file system ACLs.
>
>Of course.  Set[ug]id'ness is a OS feature.  Anyway it helps a lot, you
>might restrict the access to the $CVSROOT, so that nobody can touch it,
>except when using CVS.

I think you misunderstood my point.  How do you control who is allowed to
execute this setgid cvs?  One way is to use file system ACLs.  Another is
to control access to the directory that the cvs executable is in.

>> I think you don't fully understand how CVS treats file system
permissions.
>
>I have no problems with it.  One thing is to discuss how it is, another
>thing is to discuss how it should be.

I don't know enough of the details to understand why it makes a copy of the
archive file (this may be a RCS thing).  If you're able to stop this, then
maybe you have a point.  But then again, you still have to deal with the
directory permissions.  If you allow users to add or remove files, then
they must have write permissions to the directories.  If they have
directory write permissions, then they can remove any file within that
directory even if they have no permissions to the file.  From another POV,
I think it's no accident that SSH keeps its files in a separate directory
that has extremely limited permissions.

Noel




This communication is for informational purposes only.  It is not intended as
an offer or solicitation for the purchase or sale of any financial instrument
or as an official confirmation of any transaction. All market prices, data
and other information are not warranted as to completeness or accuracy and
are subject to change without notice. Any comments or statements made herein
do not necessarily reflect those of J.P. Morgan Chase & Co., its
subsidiaries and affiliates.