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
Received on Thu Aug 12 19:33:43 2004