Community technical support mailing list was retired 2010 and replaced with a professional technical support team. For assistance please contact: Pre-sales Technical support via email to sales@march-hare.com.
Hi Tony, Tony Hoyle wrote: > Mike Wake wrote: > >> Hi All, >> >> Does anyone know if is possible to reject a cvs login using SSPI for >> some users that are not a member of a particular group? Ie >> Effectively completely hide the existance a repository that users are >> not authorised to see without resorting to a different protocol and/or >> maintaining a local passwd file? > > > Which error message? AFAIK this kind of information leak shouldn't > happen (there are certain fatal error messages that will give the > information for admin purposes, but they're rare). > Highlighting an existing sandbox of a properly authorised and logged in account and typing "cvs version" into the command window of WinCVS 1.3.21.1 I get this Client: Concurrent Versions System (CVSNT) 2.0.58d (client/server) Server: Concurrent Versions System (CVSNT) 2.0.58d (client/server) Using the GUI to checkout the "_all" module defined in the modules file as user that is not a member of "CVS_Access_Lockdown" but who has previously successfully logged in. The command window reveals cvs -d sspi;username=naughtyuser;hostname=mycvsserver:/MyLockedDownRepos checkout _all (in directory D:\HowItCouldBeDone) cvs [checkout aborted]: cvs [server aborted]: Repository directory /home/cvsuser/CVSREPOS_LOCKDOWN/MyLockedDownRepos does not exist: Permission denied The PServer file on the server contains Repository0=/home/cvsuser/CVSREPOS_LOCKDOWN/MyLockedDownRepos Repository0Name=/MyLockedDownRepos And I have a line for AllowTrace=1 which is commented out. > IIRC 2.0.58d doesn't use .owner and .perms any more. Would you recommend that I remove them if I am totally sure that I don't want to revert to an older version of the server (Be assured that I don't, If it were possible for this version ;) )? > Just a chacl on the root of the module will automatically block any > lower level users from using it, as permissions are recursive unless > overridden specifically. You can set the permissions for the whole > repository as: > > cvs co -d repos . > cd repos > cvs chacl -u CVS_Access_Lockdown -a read,write,control,tag,create > cvs chacl -a noread,nowrite,nocontrol,notag,nocreate > (I think this works in 58d anyway). > I haven't played with/completely missed the deny ( ie noread, nowrite ) stuff. When I was experimenting with this a few months ago I was trying to explicitly and recursively allow read by users that fall into the "default" category. And I was not not setting anything else for the default user. I was assuming that not setting "write" was equivalent to using "nowrite" Using this assumption I thought I had to set acls on all directories and it was here that I was running into bugs with the chacl -R option on deep directories while trying to do this. Instead I should have just been denying everything except "read" for the default users at the root level and then explicitly allowing operations for the relevant users and groups in the sections of the repository that are required. Is this correct? If it is, I hope helps someone else get it. Cheers Mikew