[cvsnt] Authenticated users importing modules which they don't have NTFS access too.

BenM benmeadowcroft at gmail.com
Wed Apr 6 14:56:10 BST 2005


Hi,
I have a problem with CVSNT 2.0.58d allowing users to partially import
modules into the CVS hierarchy at places which they don't have write
access too. Leaving behind half imported modules in areas of the
repository.

My server setup is as follows:
Windows 2003 
CVSNT 2.0.58d
sspi authentication is the default
SystemAuth=Yes, I'm using integrated windows authentication.

single repository /cvs
modules are placed in a hierarchy, e.g.
/cvs/projects/proj1/module1
/cvs/projects/proj1/module2
/cvs/products/proj1/moduleA

etc.

users are given assigned to groups which have full control over
certain areas of the repository but no control over other areas. e.g.
UserA belongs to the proj1 group and has full control of
/cvs/projects/proj1/* and no control over areas higher up the
hierarchy. However when they wish to import a module, if they don't
specify the proper path e.g. "/projects/proj1/newmod" but rather
"newmod" then the new mod directory gets created as /cvs/newmod and
then the import fails with error messages about not being able to
change the permissions on the files.

Here's the message when I try and do this using WinCVS:

Filtering 'C:\newmod\'...
cvs -z9 import -I ! -I CVS -m "no message" newmod avendor arelease (in
directory C:\newmod)
N newmod/.project
cvs server: cannot change mode of file /cvs/newmod/.project,v: Permission denied

No conflicts created by this import

***** CVS exited normally with code 0 *****

I'm guessing that the directories and files are initially created by
the SYSTEM account and then CVSNT tries to change all the permissions
to those of the authenticated user? I'd rather not have to do this
manually clean up miscreated directories everytime someone screws up
and improts a module into the wrong place. Any ideas on how I can fix
this?



More information about the cvsnt mailing list