[cvsnt] SSPI Protocol security

[John Peacock]

Thomas Muller wrote:
> CvsNt is unning on a box as administrator (configured in "Log on" tab in she
> service console). On this box I've added a user which is also added in the
> repository's passwd file. The user exists both on the host running CvsNt and
> on the host with the share, with the same password, and is a member of the
> administrators group on both hosts. I've even tried to run CvsNt as this
> user, but no luck. Cvs reports "[server aborted]: Cannot access
> G:\BaseCamp\VersionControl: Permission denied".
> 

There are a couple of things that are "wrong" with your configuration; you might 
be able to get it to work this way, but it is not a supported configuration.

1) Repositories on shares are not supported; not withstanding the fact that CVS 
has very weak locking support, the basic Win security model makes it quite 
painful to configure properly.  You may/will have repository corruption 
occurring on occasion.  The use of non-local repository is strongly discouraged.

2) Drive maps are an interactive client feature, not something that services can 
use; it doesn't matter how you create the drive map, it is not visible to the 
service even if mounted by the same user.

3) Running services as an administrator account is always (IMHO) the wrong thing 
to do.  If you must use a domain account for a service, it should only be an 
ordinary account, with specific ACL rights to resources.  You may also need to 
assign additional rights to the identity, specifically "Log in as a service", 
"Act as part of the Operating System", as well as possibly "Create a token 
object" and "Replace a process level token" though I am not sure that the latter 
two are strictly required for CVSNT.

If you still want to try and get this working, you should start with trying to 
use a non-system user on a _local_ repository.  Get the rights working and make 
sure the service works completely.  Perform all steps under CVS: import, add, 
delete, update, etc.  Only when this is working 100% should you proceed to the 
next step.

Then you will need to refer to the remote repository by a UNC path, not by a 
drive mapped letter.  I would suggest using the Repository prefix in the more 
recent releases.  You will likely have to add additional ACL's to the remote 
repository to get it to work.  If you are not in a domain environment (i.e. 
workgroup), you may have better luck.  But I would suspect that performance is 
going to suffer, since the UNC drive has to be created each time the service 
runs (AFAIK, Win32 does not cache the UNC drives).

John