Does not support uid's and gid's above 65535 on x86-64

[Paul Kilgo]

I am having a problem where in my AssignUserID <Location> blocks mpm-itk will fail with an internal server error. This shows up in the log:

(itkmpm: pid=29765 uid=33, gid=33) itk_post_perdir_config(): setgid(120208): Operation not permitted

I downloaded the source code and noticed I could compile it without HAVE_LIBCAP and the error goes away. I figured this meant there was something wrong with mpm-itk's use of capabilities. In itk_pre_drop_privileges() of mpm_itk.c a comment seems to think that the CAP_SETUID and CAP_SETGID has been set previously.

I modified the code mostly through trial and error since I'm not that familiar with capabilities to come up with the patch below. This explicitly gives the process CAP_SETUID and CAP_SETGID in itk_pre_drop_privileges(). I am not sure if something else is supposed to be setting process capabilities (or I need to do that in the Apache configuration) but this seems to work.

This is mpm-itk 2.4.6-01 on Ubuntu 14.04.

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "Set-setuid-setgid-capabilities-before-privilege-drop.patch" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Juerg Walz (gw42)]

This is actually caused by a hard-coded restriction in seccomp.c . The numeric UIDs/GIDs are limited to < 65535 - I don't know why.

The attached patch removes this restriction.

[Paul Kilgo (paulkilgo)]

Juerg is right. I actually took this problem to upstream's mailing list:

https://lists.err.no/pipermail/mpm-itk/2015-November/000958.html

Juerg's patch seems to unconditionally cap gid's and uid's to UINT_MAX, which I think is 65535 on all platforms. I am not sure how that's different from current behavior, though maybe I missed something.

Regardless, I think the limits need to be set differently on different architectures to keep the 32-bit compatibility around. At least I think that's upstream's intent.

I posted a patch which fixes the problem for me to that mailing list. No one has looked it over yet. I don't have a 32-bit system handy to test but the patch is pretty simple. I don't think upstream needs the patch because, by my inspection of the latest source code, they have already fixed the problem.