[Fwd: Subversion 1.4.6 incorrect locking behavior under Mac OSX 10.4.11]

I got no responses to this on the users mailing list, any chance of a
response here ? :)

-------- Original Message --------
Subject: Subversion 1.4.6 incorrect locking behavior under Mac OSX 10.4.11
Date: Mon, 19 May 2008 13:28:10 +0100
From: Arran Cudbard-Bell <ac221_at_sussex.ac.uk>
To: users_at_subversion.tigris.org <users_at_subversion.tigris.org>

Hi,

Bug Report follows:

OS: Mac OSX 10.4.11
Protocol: SVN WebDav (Compiled with APXS Apache 2.2.4)
File System (Local): HFS+ Journaled (Case insensitive + Case Preserving)
File System (SVN Data): XSAN (CVFS)
SVN DB: FSFS

Symptoms:

Attempting to lock a file fails when the SVN Locks directory
(./repository/db/locks) is owned by a group of which the user (that
Apache is running under) is not a member of.

For example if Apache is running under user WWW and SVN data is owned by
user WWW and group SVNAdmin and WWW is not a member of SVNAdmin then the
lock will fail. If WWW becomes a member of SVNAdmin then locking will
succeed.
This is only an issue when creating new directories under
./repository/db/locks, locks may be re-used once established.

Cause (I think, please verify):
When the SVNAdmin tool creates the directory structure it sets the gid
bit (chmod g+s) on the db directory (and possibly sub directories).

This has absolutely no effect with Mac OSX as it uses Berkley permission
inheritance semantics (on creation directories inherit permissions from
their parent directory), instead of Posix semantics where the directory
inherits permissions from the user creating it (I think... correct me if
I'm wrong on this one). So there's no reason to set the gid bit on any
directories under OSX.

There is however a compelling reason not to set the gid bit under OSX. A
chmod operation attempting to set the gid bit will fail if the user
doing the chmod is not a member of the group that currently owns the
directory.

So:

1. User attempts to lock file
2. Apache process attempts to create subdir under /repo/db/locks (and
succeeds)
3. Apache process attempts to chmod subdir to match the permissions of
/repo/db/locks (I think that's what the code is saying) (and fails if
Apache is not a member of the group owning the locks directory)
4. Lock fails because of the failed chmod (that wasn't really needed in
the first place)

Workarounds:

chmod -Rv g-s /repo/db
chgrp -Rv www /repo/db

It'd be nice to have this fixed for 1.5.

Best Regards,
Arran Cudbard-Bell

-- 
Arran Cudbard-Bell (A.Cudbard-Bell_at_sussex.ac.uk)
Authentication, Authorisation and Accounting Officer
Infrastructure Services (IT Services) 
E1-1-08, Engineering 1, University Of Sussex, Brighton
EXT: +44 1273 873900 | INT: 3900
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org