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.
> From: cvsnt-bounces at cvsnt.org > [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund > Sent: Wednesday, 08 February, 2006 11:56 > > > To quote the error message: > > cannot change permissions on temporary directory > D:\CVSTEMP/cvs-serv2612 > > Why does this happen? Well, taking a quick look at the code for 2.0.51d (src/server.cpp) where this message is produced, what CVS is trying to do is create its temporary directory for this request. (Here 2612 is the PID of the CVS server process.) CVS creates the directory, then sets its permissions to S_IRWXU - full permissions for current user, no permissions for others. That's to prevent an attacker from altering the contents of the temporary directory. When this message is produced, CVS has successfully created the directory, but CVS_CHMOD has failed. (It'd be nice if CVS reported the system error code, so we'd know *why* it failed.) On Windows, CVS_CHMOD is wnt_chmod, defined in windows-NT/win32.cpp. It does a couple of things, but it appears that it only returns an error if _tchmod (the TCHAR version of Windows chmod) fails. > Absolutely every account and group > involved has Full Control on CVSTEMP and its contents, so why > does CVSNT fail to change permissions? The question really is why does _tchmod (which is actually _chmod or _wchmod, depending on what character set CVSNT is compiled for) fail? (It'd be good to run with tracing just to be sure that CVSNT is making the _tchmod call correctly, but the code is pretty simple.) I'm not actually sure how S_IRWXU is being defined here; it isn't actually defined by any of the Microsoft C headers, as far as I can tell. According to the MSDN docs I have installed here, though, _tchmod ignores everything except whether the "write" bit is set, so really it shouldn't matter. They also claim that it will only fail if the target doesn't exist. Maybe the behavior of _tchmod has changed in a recent release of the MS C7 runtime? More likely, though, it's some problem with ACLs. If the user associated with the current security token for the CVS server process has a Deny entry for the Write Attributes permission for the new directory, or if that user doesn't have an Allow entry for it, they won't be able to set the permission bits with _tchmod. (I just tried it.) I'd double-check what account the CVS server is using, then look at effective permissions for the D:\CVSTEMP directory for that user. > And what kind of > permissions are being changed, really? It *is* already *full > control* so why change it? Because full control is a security risk. > And why for the cvs ls command? Presumably ls needs to use the tempdir, or because the server always creates the tempdir regardless. I know, that's not much help. -- Michael Wojcik Principal Software Systems Developer, Micro Focus