Re: CVS, RSH and direct access to repository

[Mark D. Baushke]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Jeeva Sarma <address@hidden> writes:

> I want to know if there is any method to prevent users
> from directly accessing repository.

Sure. Control the access to the machine. If they do not have
the opportunity, then it seems likely they will not be able
to do anything directly without proper authorization.

> I read of one method, using Openssh and restrict users to
> one command, 

Yes, this is the an excellent approach to choose. If your
source is important, then it deserves to be protected.

> but that would prevent the users from even logging on to
> the machine.

Yes, that is true.

> Some developers use this machine for other purposes (do
> their regular development and stuff). 

This is a bad situation. How much would it really cost you
to have a dedicated machine as a cvs server? How much would
it cost if your developers damage your source repository?
Do the risk analysis and cost analysis and see if you have
enough justification for a dedicated cvs server. If so,
that is the way to go.

> We plan to have CVS server on solaris, windows clients
> using ssh authentication. Pls advice.

If you can do it, make the cvs server a single-purpose box,
then you can implement restricted shells via ssh that only
allow the cvs command to be executed. This means that only
the cvs command may be used to modify the repository. This
is a good situation.

If that solution is not available, then you could look into
making the cvs executable be set-gid only on the cvs server
and have the directories that hold the repository only be
set-gid to that group and have no users other than the
administrator in the group (ideally only via sudo commands
or some other mechanism that logs what happens). The
downside here is that a user who commits or tags a file will
end up as the owner of the file. The hack for this problem
is to run a set-uid program that changes the ownership of
the ,v file to a special 'cvs' account, but does so only for
files and directories in the repository hierarchy and makes
sure that they are only ,v files that are so updated. This
reduces the exposure against accidental modifications to the
repository, but may not be able to stop someone determined
to hack the repository.

While it may be possible to do some kind of hackery to get
:pserver: to keep a separate userid space from your real
users, I believe that way lies madness and I personally do
not consider the :pserver: as a 'secure' option for a
production network as anything other than a read-only
'guest' checkout.

        Good luck,
        -- Mark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQFAB4JV3x41pRYZE/gRAoPpAKCPWfUzFM8LrhKc8BW2ex545E345gCguEUA
1H/Y95rsnkfSKroytRQl2JY=
=VQWZ
-----END PGP SIGNATURE-----