RE: New update to the CVS ACL patch to support user groups

[Noel L Yap]

>[ On Wednesday, July 25, 2001 at 12:18:14 (-0700), Mark wrote: ]
>> Subject: RE: New update to the CVS ACL patch to support user groups
>>
>> Just preventing write access, (cp, mv, chmod, etc...) (ls, cd, cat, etc.. are
>> okay)
>
>Well then I'm sorry, but you don't have any such assurance now that
>people can't mess directly with the repository files with cvspserver.

I think many users want to avoid, rather than prevent, write access.  It takes
much more effort to prevent inadvertent repo writes.  IMHO, it's worth some
effort, but not everyone agrees on how much.

>The most effort required to manage a CVS repository on a Unix host
>is actually in the maintenance of correct ownerships and permissions in
>the repository, and this only really becomes a burden on the superuser
>when the repository resided on a system that requires superuser access
>to "chown" a file or directory.  Even though "chown" only needs to be
>restricted when filesystem quotas are implemented, many systems which
>support quotas restrict chown regardless of whether quotas are enabled
>and in use or not, which is silly and frustrating, but that's life.

At one time, I had written a loginfo script to help with this.  It's not a
panacea, but it did take care of the daily maintainance.

>An often quoted statistic suggests that over 80% of known (reported)
>attacks are by inside users already authorised for some degree of access
>to the network or system being attacked.  You won't know you have a
>problem until it's too late, an then you'll have a very big problem.  :-)

I think backups are a viable way to mitigate such risks.  It's up to the company
to do a proper risk and cost analysis.

>CVS can use any external remote job execution tool.  SSH, RSH, SRP,
>Stunnel, etc., all come to mind.

I thought SRP (secure remote password) was an authentication protocol only.  Are
we talking about different SRP's?

>  All of them require real Unix accounts
>on the server though.  All of them require that the server trust the
>client and vice versa.  Some of them also require that the network be
>physically and logically secure (but not SSH or SRP or Stunnel).

I thought SSH's trust for the server is needed only for the initial server host
key distribution on the client.  If this is so, depending on the established
procedures to obtain the host key, the SSH client needn't trust the server at
all.

>If you want a secure CVS server you really Really REALLY must have Unix
>accounts.  They're the cornerstone for the Unix security model (and
>indeed for any host-based security on any multi-user system!).

I agree with Greg here.  You need to make a choice of how much security vs
simplicity you want.

The simplicity may get you something that's less accident-prone, but that
doesn't mean it's more secure.

>No, there really is no place for cvspserver.  There never ever was.
>Even if you don't want *any* security you can still use simple remote
>job execution tools external to CVS.  Every book on TCP/IP programming
>contains at least one example of how to write such a tool!

In the strictest sesne of the word "necessary", I'd say that pserver isn't
necessary considering one could write such a tool.  I think we have something
that does this written in perl for use during installation (so that files are
installed as some other user).  In this case, we sacrificed security for less
accident-proneness (although I suspect the tool writer didn't even consider this
;-}.

>Maintaining filesystem permissions bits is a necessary part of all CVS
>repository administration (well, not the full ACL stuff -- that's only
>an optional feature you might want in very specific scenarios).

In fact, I know of no VC tool that you don't have to deal with these issues.
Some do provide it within the tool itself, but I prefer when this is left to the
file system.

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.