Re: history and val-tags locks.

[Derek Price]

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

Mark D. Baushke wrote:

> For pserver, the administrator has full control over
> the command line.
>
> For server, if the administrator is using a
> restricted shell for users, they may or may not be
> able to restrict command-line arguments (it
> depends on how the restricted shell is
> implemented).


For server, OpenSSH, at the very least, allows the command line to be
restricted.  Are we really worried about the security of the command
line if the user is still using a vulnerable tool like RSH to access
their server?

> I have used (am using) a set-gid cvs and it does
> not disable the use of UNIX uids at all. Yes, it
> does inhibit gids as the entire repository uses
> the same gid ('cvs'), but the cvs_acls deals with
> permissions for commit and anyone with a login to
> the special-purpose CVS server has already been
> granted read permissions for checkout in any case.
>
> I will grant you that this is not necessarily a
> normal situation, but I make note of it as setuid
> is not the only configuration possiblity here.


Well, no, but for a secure setup, aren't we still recommending that the
admin rely on a transport such as SSH and filesystem permissions or ACLs
for access restriction in the repository?  The stated position of the
CVS developers has been that users should rely on systems that get more
thorough security audits than CVS does to provide the secure portions of
their setups.  This means using SSH as a transport, restricting the
command line, and relying on system permissions/ACLs to restrict access
to the various portions of a repository.

setuid and setgid CVS executables both disable the fine-grained access
restrictions that would otherwise be possible, limiting you, basically,
to one group per repository/server.

> As an alternative, I would not have a problem with
> allowing cvs to be built with a list of
> directories that could be searched for a valid
> config file. So, a --enable-config-prefix=/etc/cvs
> might mean that /etc/cvs/$CVSROOT/config would looked
> at before $CVSROOT/config ... doing that means that
> the administrator would still have complete control
> over the configurations and would not need to rely
> on the user to make the right choice.


This compromise does sound reasonable.  Would you then consider a
default value of `--enable-config-prefix=/etc' as reasonable here?  i.e.
the ability to override the config would default to `on', with access to
config files restricted to /etc and subdirs.

> The downside is that src/sanity.sh tests for this
> case would be more painful.


Well, we could test that the restricted paths were disabled, at least.

> As far as your src/sanity.sh tests, I believe you
> should use the -c CONFIG-FILE to determine if cvs
> has been configured with this option or not before
> you fail the tests (granted STABLE does not have
> that available to sanity.sh)


If it defaults to on, with config-prefix used as you suggest, would you
still consider this last important?

Regards,

Derek
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCi525LD1OTBfyMaQRAjERAKDuDciHLatseYmpN/PlQABI4Kcy7gCghAs8
KpNygtYAx/ZTx2+JWGjNaQI=
=G/xc
-----END PGP SIGNATURE-----