On 04/02/14 04:47 PM, Steinar H. Gunderson wrote:
On Tue, Feb 04, 2014 at 04:28:18PM -0500, Jason Rhinelander wrote:My guess here is that something in the new apache/mpm-itk combination is removing the ability to seteuid/setegid sometime after the seteuid is done for the VirtualHost, and this is breaking anything later in the request that needs to do a seteuid, even for a trivial seteuid to the already active euid.There are really only two things that can cause this, namely capabilities and the seccomp v2 sandbox. My guess would be on the latter. However, I don't see how this can cause the original bug?
Indeed you're right. I'll refile that as a new bug shortly.As for the original bug report, I poked around with adding some debugging for bmc's test case with git (with s/bmc/jagerman/g), and there seems to be a problem in when itk_post_perdir_config is being called under the new version.
It's definitely *not* a problem with the previous request interfering with the later request: my initial and subsequent requests are handled by two entirely different processes.
What I'm seeing is the following, for a single request handled by /usr/lib/git-core/git-http-backend per bmc's config:
For 'POST /git/jagerman/foo.git/git-receive-pack', I see:- itk_post_perdir_config gets called with r->uri = /git/jagerman/foo.git/git-receive-pack and r->filename = /usr/lib/git-core/git-http-backend.
setgid/initgroups/setuid runs and succeeds.- in the same request, itk_post_perdir_config gets called again, this time with r->uri = /jagerman/foo.git/git-receive-pack and r->filename = /var/www/html/jagerman.
Notice the initial "/git" is gone now from r->uri.It's this second call to itk_post_perdir_config that fails, because for that uri (/jagerman/foo.git/git-receive-pack), which doesn't exist, we aren't matching the <LocationMatch> with the AssignUserID anymore. Thus the default (www-data:www-data) user applies.
That fails, of course, because we already setuid to 1000 during the first itk_post_perdir_config call: so the initgroups fails, and we trash the connection.
(I should also add that the POST above is actually the second request: there are also two initial GETs: the first, unauthenticated, for which itk_post_perdir_config is called once. The second, with authentication, yields exactly the same double-call behaviour. No error is occurring there, however, because both the (correct) initial call and second call (this time with r->uri = /jagerman/foo.git/info/refs) map to the same www-data user, and so the second set of setgid/setuid/initgroups calls succeeds because it's not actually trying to change anything).
Comparing the old code to the new, the apache hook setup is quite different: itk_post_perdir_config used to be set up via ap_hook_header_parser(...) (in apache2 2.4.6-3), while it's now ap_hook_post_perdir_config(...).
I don't know where to go from here, but hopefully this helps you figure out the issue.
-- Jason Rhinelander
smime.p7s
Description: S/MIME Cryptographic Signature
