-----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----- _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs