You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Max Bowsher <mo...@cam.ac.uk> on 2004/08/12 12:48:04 UTC
APR bug breaks multiuser working copies again in 1.1.0-rc2
There is a bug in the APR bundled with apache 2.0.50:
apr_dir_make(APR_OS_DEFAULT) creates dirs with the sticky bit set.
svn-1.1.0 *MUST NOT* be rolled with this apr, or it will kill the ability
for multiple users to work with a single working copy.
A fix is in apr cvs. apr_file_info.h should be manually updated to r1.40.2.6
to include the fix.
Max.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: APR bug breaks multiuser working copies again in 1.1.0-rc2
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2004-08-12 at 07:48, Max Bowsher wrote:
> There is a bug in the APR bundled with apache 2.0.50:
>
> apr_dir_make(APR_OS_DEFAULT) creates dirs with the sticky bit set.
>
> svn-1.1.0 *MUST NOT* be rolled with this apr, or it will kill the ability
> for multiple users to work with a single working copy.
>
> A fix is in apr cvs. apr_file_info.h should be manually updated to r1.40.2.6
> to include the fix.
Max, can you add this to STATUS, just so we don't forget about it?
We're going to release an RC3 about a week before 1.1.0 final, and this
is definitely one of those things that needs to be on the RC3 "to-do"
list... and STATUS seems to be the place for that.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: APR bug breaks multiuser working copies again in 1.1.0-rc2
Posted by Greg Hudson <gh...@MIT.EDU>.
On Fri, 2004-08-13 at 11:55, kfogel@collab.net wrote:
> Thanks, Greg, and +1 on the workaround strategy for now. We would
> undo it after the next httpd release, I guess, and just tell people to
> upgrade to avoid the bug?
No reason not to leave the workaround in for a long time. It only kicks
in if it detects that Subversion is being compiled against a buggy
version of APR.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: APR bug breaks multiuser working copies again in 1.1.0-rc2
Posted by kf...@collab.net.
Greg Hudson <gh...@MIT.EDU> writes:
> Okay, here are my findings:
>
> * For background, the bug is that if you create a directory with
> APR_OS_DEFAULT, it tries to create the directory with the setuid,
> setgid, and sticky bits set. Since there is no such thing as a setuid
> directory and the setgid bit is generally harmless, the main problem is
> the sticky bit. This bug was introduced into the 0.9 branch on May 5
> and fixed on June 25.
>
> * httpd apparently doesn't use APR releases; it just pulls down the
> head of APR_0_9_BRANCH at release time. (Not really great for QA.) For
> 2.0.50, they just happened to pull it down at a time when this bug was
> present.
>
> * We could try to convince httpd that this bug is bad enough to
> warrant an httpd 2.0.51, but that seems like a dead end since I doubt
> httpd creates directories very often. Perhaps we could convince them to
> fix their release practices and start using APR releases as a way of
> reducing the likelihood of this kind of lossage in the future.
>
> * We could bundle the APR from httpd 2.0.49, but that wouldn't fix the
> problem for people who build httpd first and then use the resulting
> APR. (Of course, those people are already losing with svn 1.0.)
>
> * I believe we can work around the problem in Subversion by testing
> for #if (APR_OS_DEFAULT & APR_GSETID) and using a perms value other than
> APR_OS_DEFAULT in that case. We would have to wrap ten uses of
> apr_dir_make() in three files, although perhaps most of those uses could
> just be permanently converted to use svn_io_dir_make().
>
> I will get started on the workaround, since I can't see a better
> solution.
Thanks, Greg, and +1 on the workaround strategy for now. We would
undo it after the next httpd release, I guess, and just tell people to
upgrade to avoid the bug?
-K
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: APR bug breaks multiuser working copies again in 1.1.0-rc2
Posted by Greg Hudson <gh...@MIT.EDU>.
Okay, here are my findings:
* For background, the bug is that if you create a directory with
APR_OS_DEFAULT, it tries to create the directory with the setuid,
setgid, and sticky bits set. Since there is no such thing as a setuid
directory and the setgid bit is generally harmless, the main problem is
the sticky bit. This bug was introduced into the 0.9 branch on May 5
and fixed on June 25.
* httpd apparently doesn't use APR releases; it just pulls down the
head of APR_0_9_BRANCH at release time. (Not really great for QA.) For
2.0.50, they just happened to pull it down at a time when this bug was
present.
* We could try to convince httpd that this bug is bad enough to
warrant an httpd 2.0.51, but that seems like a dead end since I doubt
httpd creates directories very often. Perhaps we could convince them to
fix their release practices and start using APR releases as a way of
reducing the likelihood of this kind of lossage in the future.
* We could bundle the APR from httpd 2.0.49, but that wouldn't fix the
problem for people who build httpd first and then use the resulting
APR. (Of course, those people are already losing with svn 1.0.)
* I believe we can work around the problem in Subversion by testing
for #if (APR_OS_DEFAULT & APR_GSETID) and using a perms value other than
APR_OS_DEFAULT in that case. We would have to wrap ten uses of
apr_dir_make() in three files, although perhaps most of those uses could
just be permanently converted to use svn_io_dir_make().
I will get started on the workaround, since I can't see a better
solution.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: APR bug breaks multiuser working copies again in 1.1.0-rc2
Posted by Ben Reser <be...@reser.org>.
On Thu, Aug 12, 2004 at 01:48:04PM +0100, Max Bowsher wrote:
> There is a bug in the APR bundled with apache 2.0.50:
>
> apr_dir_make(APR_OS_DEFAULT) creates dirs with the sticky bit set.
>
> svn-1.1.0 *MUST NOT* be rolled with this apr, or it will kill the ability
> for multiple users to work with a single working copy.
>
> A fix is in apr cvs. apr_file_info.h should be manually updated to r1.40.2.6
> to include the fix.
I'm -1 on applying *ANY* patches to apr in our tarball.
If we start applying patches we'll magically work with the in-tree APR
and be broken for people using the APR included with Apache. We either
need to work around the APR problem or just document this as a
limitation of APR and point users to the patch to fix APR.
--
Ben Reser <be...@reser.org>
http://ben.reser.org
"Conscience is the inner voice which warns us somebody may be looking."
- H.L. Mencken
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org