[cvsnt] CVSNT client resets ACLs?

Arthur Barrett arthur.barrett at march-hare.com
Tue Jan 27 23:21:42 GMT 2009


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.


Oliver,

> we have a mixed environment and thus both Windows and Linux 
> clients commit to the CVS repo in question. The server is 
> running good old CVS, not CVSNT (apparently no way to upgrade 
> :-( ...).

I suppose security and audit compliance means nothing to your
orgnaisation, let alone productivity...  

Certainly upgrading legacy systems has a cost and before such upgrades
are embarked upon the benefits need to be documented and weighed against
the costs - however if there are clear benefits in upgrading and clear
costs to continuing to use old insecure unproductive software then those
who argue for the status quo need to be prepared to pay for those costs.

Suggest deducting the costs of lost productivity and the costs of
performing manual audits from the sysadmins wage and you'll see a
different result...

Specifically by not using CVSNT server you are missing out on: user
defined change sets, merge tracking, auto merges (mergepoint), real ACLs
(including branches), failsafe audit, commit identifiers (some people
call this atomicity), secure repositories (aliases, mode, dynamic
protocol disabling etc, chroot jail etc).

> Anyway, it appears that on my machine (Windows 2003) the 
> CVSNT client included in TortoiseCVS takes away the right to 
> execute a file on occasion (this is reflected by the x bits 
> on that file in the repo itself), which is highly annoying 
> with scripts (which always need this, be it .cmd or .pl).

The 'x' bit is the mode not the ACL.

CVS server stores the 'mode' of the checked out file in the 'mode' of
the RCS file (ie: to have build.sh as executable then build.sh,v needs
to be executable) - which some sysadmins see as a security risk - hence
why CVSNT Server stores the executable bit in the RCS file itself as an
attribute.  

Every CVS client (CVS, CVSNT etc) sends the 'mode' of the file to the
server with each commit - however on windows there is no 'execute bit'
(executable files are defined based on the extension or the environment
variable PATHEXT) - so on windows the 'execute' bit is always removed on
commit.

With CVSNT client you could try experimenting with "set CYGWIN=ntsec" or
"set CVSNT=ntsec" to see if some combination of ntsec, ntea, nontsec,
nontea works better.

> Any chance to inhibit this behavior through configuration? 
> I'd prefer if the client wouldn't meddle with my ACLs and 
> simply inherit from the parent folder.

The 'mode' of the file is not an ACL by any definition, please do not
confuse terms...

Regards,


Arthur




More information about the cvsnt mailing list
Download the latest CVSNT, TortosieCVS, WinCVS etc. for Windows 8 etc.
@CVSNT on Twitter   CVSNT on Facebook