[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: APR bug breaks multiuser working copies again in 1.1.0-rc2

From: <kfogel_at_collab.net>
Date: 2004-08-13 17:55:23 CEST

Greg Hudson <ghudson@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
Received on Fri Aug 13 19:31:37 2004

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.