bug-cvs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: history and val-tags locks.


From: Derek Price
Subject: Re: history and val-tags locks.
Date: Tue, 17 May 2005 12:11:54 -0400
User-agent: Mozilla Thunderbird 1.0.2 (Windows/20050317)

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  <address@hidden>

    * 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





reply via email to

[Prev in Thread] Current Thread [Next in Thread]