[cvsnt] Pserver authentication stopped working after upgrade...

[Michael Wojcik]

> From: cvsnt-bounces at cvsnt.org 
> [mailto:cvsnt-bounces at cvsnt.org] On Behalf Of Bo Berglund
> Sent: Wednesday, 08 February, 2006 13:17
> 
> On Wed, 8 Feb 2006 09:49:26 -0800, "Michael Wojcik"
> <Michael.Wojcik at microfocus.com> wrote:
> 
> >> 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?
> >
> >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.)
> 
> Actually, the directory is *not* created. I had a look at the temp
> folder while running these commands. Unless of course cvs first
> succeded to create the dir, then failed changing permissions and then
> finally vcleaned up by removin the dir again. This would not be slow
> enough to show up in Windows Explorer.

That's certainly possible, but it's made me think of another
possibility: the directory creation failed, but CVS failed to detect the
error, and then _tchmod failed with ENOENT.

(Also, I should note again that I'm not looking at the 2.5 sources; I
have 2.0.51d on this machine at the moment.  Something may have changed
in server.cpp.)

CVS determines that directory creation has succeeded when mkdir_p
returns 0.  mkdir_p actually returns errno if a call to CVS_MKDIR fails;
if somehow CVS_MKDIR can fail but set errno to 0, CVS will incorrectly
decide that mkdir_p succeeded.  CVS_MKDIR on Windows is actually
wnt_mkdir (in windows-NT/mkdir.cpp).  wnt_mkdir calls
CDirectoryAccess::mkdir (I don't know why it doesn't just use _tmkdir),
and then calls _dosmaperr(GetLastError()) to set errno if that fails.

_dosmaperr should set errno to EFAULT for unrecognized errors, and to
the value of the "dos" member of the appropriate entry in the "errors"
array if it finds the system error code there.  Those are all valid
non-zero errno values, so it doesn't appear that _dosmaperr should leave
a 0 in errno.

CDirectoryAccess::mkdir appears to return false (indicating failure and
triggering the call to _dosmaperr) if CreateDirectory fails.
CreateDirectory is a Win32 API call.  It's possible that it's failing
but reporting success, but that seems unlikely.

The call to CreateDirectory does also transcode the directory name (via
CFileAccess::Win32Wide), so it's possible that something's going wrong
there, and the directory's being created with the wrong name, but again
that seems unlikely.

On the other hand, since you only now started having this problem, it
may be something has changed in all of this since 2.5 which is now
masking the failure.

> I looked up the security settings for the CVSTEMP folder and went over
> the Advanced page for every single entity listed to have permissions
> here. THey had all the checkboxes for allow checked and none for deny
> checked...

What you really want to check is the "Effective Permissions" tab.  ACLs
are very complicated, what with users and groups, multiple group
membership, deny and allow rules, and inheritance.  And this sort of
operation is additionally complicated by the fact that an object is
being created and modified: the ACL for the parent object (plus any
inherited from ancestors) control the creation process; then changing
the object will be governed by the ACL of the new object plus any
inherited from ancestors.

> >I'd double-check what account the CVS server is using, then look at
> >effective permissions for the D:\CVSTEMP directory for that user.
> 
> I also did the following:
> We have two CVS user groups in the domain, CVS_Admins (where I am the
> only member) and CVS_Users (where all of my developers are members).
> So we added the cvs_setup domain user account to CVS_Users group and
> hoped that this would fix the problem.
> But not, the same error for pserver users aliased to cvs_setup.
> 
> Then I even went as far as rebooting the CVSNT Win2000 Server PC in
> order for it to refresh the security tokens from the domain
> controller. But no-go, same error again after startup.
> 
> Finally as a check I again added the domain\cvs_setup account to the
> local Administrator group. This again made the pserver operations work
> properly! But I *really* do not want to be forced to have the pserver
> users operate as a server admin!!!!

Understandable.

Well, it looks like you've confirmed that the CVS server is operating
under the domain\cvs_setup account, anyway.  That's useful.

When you checked the permissions for D:\CVSTEMP, did you use the
Effective Permissions tab (Security -> Advanced -> Effective Permissions
-> Select and enter "domain\cvs_setup") to verify that you were looking
at the results for that user account, including all inherited
permissions?

If that looks OK, then I'd try the following:

- Use runas to start a command prompt as the domain\cvs_setup user.
(You may have to temporarily enable login for that user, etc.)

- cd to d:\cvstemp and create a directory with md.

- If that succeeds, take a look at the effective permissions on the new
directory - it may be that you're losing some permissions on new objects
because something's not inheritable.

- If they look OK, try setting the read-only flag with attrib +r.
That's not exactly what CVS is doing, but it should fall under the same
rules, since _tchmod only sets or clears the file's read-only attribute
flag.

If all of that doesn't work, I'll try taking a look at the 2.5 sources
tomorrow, if I have time, to see if something's different there.  (It
just occurred to me, for example, that maybe in 2.5 the other calls that
wnt_chmod makes might affect its return code, unlike in 2.0.)


-- 
Michael Wojcik                  Software Systems Developer, Comms 
phone 517 676-0892              Micro Focus 
mobile 517 862-9464             Mason, Michigan