Derek Price wrote: >Derek Price wrote: > > > >>I see your point. What about `cvs server'? I can see both setups being >>useful... an admin who allowed users access to the CVS repository would >>probably prefer not to allow the config file to be specified whereas an >>admin who restriced the command that SSH users could run to a particular >>shell script that provided the -c option wouldn't mind... perhaps it >>should be a compile time option, with the default to disallow it. >> >> > > >On further consideration, if we are going to consider a configurable >config path with other CVS modes a security risk, then using it with >pserver has to be considered a security risk too. There is nothing >stopping a creative user with shell access to a machine from using >pserver mode to access their repository. > >I might argue that any administrator worried that much about security >should be disabling shell access to the machine anyhow, which would deal >with any insecurity resulting from a configurable config path, but I >don't feel so strongly about it that I wouldn't happily install it as a >compile-time option that defaults to off. > >
I've implemented this as an option to server & pserver. Installing as a global option would have create problems in multiroot mode anyhow. Preliminary patch against 1.11.x attached. The final version will go into feature - I'm not advocating putting this in stable, but this is what I have now and I thought I would request a review. This patch also finally disables the sourcing of the ~/.cvsrc file for the server commands as an added protection against a user setting the path to the config file. 2005-05-17 Derek Price <[EMAIL PROTECTED]> * configure.in: Add --enable-config-override. * main.c (main): Don't source .cvsrc in server mode. Remove obsolete comment. * parseinfo.c (ConfigPath): New global. (parse_config): Open ConfigPath when provided. * server.c (server): Parse -c option. * sanity.sh (server_usage): New static global. (sever): Add tests of ConfigPath and .cvsrc. I've been thinking about this more, and I'm starting to feel that as an option to server/pserver/etc, this really isn't so insecure. In general, an admin will be able to and probably does restrict the arguments to the server & pserver commands, and a user with shell access to the server could run a hacked CVS against a repo or even alter a repo directly anyhow, so the argument about security is mostly moot. The only exception would be where the admin only used a setuid CVS executable to restrict repo access to a specific CVS executable. I'm not sure how common this is however, as it also disables the ability to use UNIX uids & gids for finer control over read & write access. Regards, Derek _______________________________________________ Bug-cvs mailing list Bug-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/bug-cvs