:strip_icc():strip_exif()/u/32282/ik0n.jpg?f=community)
Zit even te klooien met in een CVS repository waarin ik de access rights van bepaalde users wil limiteren. Kan geen duidelijk antwoord bij de cvsnt mailing list ontfrutselen, weet iemand het hier misschien?
Zowel server als client pc's runnen allemaal cvsnt 2.0.58d, is het dan correct om als user1 (vanaf een client bak) het volgende te doen:
cvs chacl -u user2 -a noread bla.h
...in een dir waarvan user3 de owner is?
(let op: ik geloof dat cvsnt sinds enige tijd een eigen ACL implementatie heeft, dus mocht dit niet 100% overeenkomen met normale cvs ACL commando's dan kan dat kloppen)
Houdt "noread" in dat user2 een error krijgt als hij bla.h probeert te updaten/checkouten? En zoja, kan ik ook zorgen dat hij een file of dir gewoon niet ziet? Dus dat voor een bepaalde user wanneer hij de hele zooi uitcheckt of update, het net is alsof die file of dir geeneens bestaat.
Het probleem is dat het niet doet wat ik wil, user2 kan gewoon bla.h uit de repository halen en committen. Heb ook nowrite geprobeerd, idem: user2 kan nog steeds changes committen. Heb het ook getest in een dir waarvan ik (user1) zelf de owner ben, maakte geen verschil. En ik heb het ook vanaf de server geprobeerd maar daar kreeg ik een error, je moet dit kennelijk als client instellen? (en is dat niet onveilig eigenlijk?)
Wellicht kan ik dit ook op andere manieren wel voor elkaar krijgen, met NTFS rechten (server is win2k met ntfs) of door meerdere repositories te gebruiken, maar dat zuigt want:
- Op de cvsnt server maakt iedere cvs user nu gebruik van hetzelfde win2k user account (een guest account genaamd "CvsDummyUser"), ik wil deze zooi namelijk alleen op database-niveau regelen en niet met machine-afhankelijke file/user rechten gaan klooien. Mocht ik deze repository morgen op een andere bak moeten hosten dan wil ik daar niet al die NTFS file rechten instellingen weer opnieuw moeten uitvoeren.
- Er zijn bijvoorbeeld libraries die door sommigen wel gelezen maar niet veranderd moeten worden, diezelfde libs moeten door anderen wel veranderd kunnen worden, dus opdelen in verschillende repositories gaat niet echt. Bovendien moet ik dan voortaan elke keer allerlei dirs uit een heleboel veschillende repositories gaan updaten, nu krijg ik gewoon met één update altijd alle changes van iedereen binnen.
Zowel server als client pc's runnen allemaal cvsnt 2.0.58d, is het dan correct om als user1 (vanaf een client bak) het volgende te doen:
cvs chacl -u user2 -a noread bla.h
...in een dir waarvan user3 de owner is?
(let op: ik geloof dat cvsnt sinds enige tijd een eigen ACL implementatie heeft, dus mocht dit niet 100% overeenkomen met normale cvs ACL commando's dan kan dat kloppen)
Houdt "noread" in dat user2 een error krijgt als hij bla.h probeert te updaten/checkouten? En zoja, kan ik ook zorgen dat hij een file of dir gewoon niet ziet? Dus dat voor een bepaalde user wanneer hij de hele zooi uitcheckt of update, het net is alsof die file of dir geeneens bestaat.
Het probleem is dat het niet doet wat ik wil, user2 kan gewoon bla.h uit de repository halen en committen. Heb ook nowrite geprobeerd, idem: user2 kan nog steeds changes committen. Heb het ook getest in een dir waarvan ik (user1) zelf de owner ben, maakte geen verschil. En ik heb het ook vanaf de server geprobeerd maar daar kreeg ik een error, je moet dit kennelijk als client instellen? (en is dat niet onveilig eigenlijk?)
Wellicht kan ik dit ook op andere manieren wel voor elkaar krijgen, met NTFS rechten (server is win2k met ntfs) of door meerdere repositories te gebruiken, maar dat zuigt want:
- Op de cvsnt server maakt iedere cvs user nu gebruik van hetzelfde win2k user account (een guest account genaamd "CvsDummyUser"), ik wil deze zooi namelijk alleen op database-niveau regelen en niet met machine-afhankelijke file/user rechten gaan klooien. Mocht ik deze repository morgen op een andere bak moeten hosten dan wil ik daar niet al die NTFS file rechten instellingen weer opnieuw moeten uitvoeren.
- Er zijn bijvoorbeeld libraries die door sommigen wel gelezen maar niet veranderd moeten worden, diezelfde libs moeten door anderen wel veranderd kunnen worden, dus opdelen in verschillende repositories gaat niet echt. Bovendien moet ik dan voortaan elke keer allerlei dirs uit een heleboel veschillende repositories gaan updaten, nu krijg ik gewoon met één update altijd alle changes van iedereen binnen.
