[cvsnt] CVSNT client resets ACLs?

Oliver Schneider Borbarad at gmxpro.net
Tue Jan 27 23:37:50 GMT 2009


Arthur,

thanks for your reply.

> I suppose security and audit compliance means nothing to your
> orgnaisation, let alone productivity...
I suppose, I'd be the wrong person to ask for this.

Also, it's not "my" organization, so I have no real leverage in changing it.
  
> 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).
I'll suggest it, but as I mentioned it is not up to me.

> The 'x' bit is the mode not the ACL.
I am aware of this. When mentioning ACL I am talking about the NT notion of an ACL, not whatever CVSNT has implemented as ACLs.

> 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.  
An even better reason to urge people in the company to upgrade to CVSNT. Let's see whether these arguments help.

> 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.
Wouldn't that mean that checking it out again causes the script to become non-executable after checking it out anew? Due to this mapping between NT ACLs and the file mode on the CVS server/RCS file?

> 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.
Thanks, will try that.

> The 'mode' of the file is not an ACL by any definition, please do not
> confuse terms...
I am aware of that, but apparently some kind of mapping between NT ACLs and the file mode *is* going on. And in that sense I definitely meant ACLs ;)


Thanks again for the swift and detailed reply,

// Oliver

PS: Re-sent through the list, because I replied to Arthur only accidentally.


More information about the cvsnt mailing list