On 21 May 2010 20:27, Graham Dumpleton <[email protected]> wrote: > On 21 May 2010 16:47, Graham Dumpleton <[email protected]> wrote: >> On 21 May 2010 15:16, Graham Dumpleton <[email protected]> wrote: >>> On 21 May 2010 10:00, Deron Meranda <[email protected]> wrote: >>>> On Thu, May 20, 2010 at 6:43 PM, Graham Dumpleton >>>> <[email protected]> wrote: >>>>> Okay, but more searching. Possibly need to use: >>>>> >>>>> NAME >>>>> setgroups -- set group access list >>>>> >>>>> SYNOPSIS >>>>> #include <sys/param.h> >>>>> #include <unistd.h> >>>>> >>>>> int >>>>> setgroups(int ngroups, const gid_t *gidset); >>>> >>>> setgroups() is exactly the function to use. >>>> >>>> You may want to include the <grp.h> header too for better >>>> portability. >>>> >>>> Anwyay, that's why I had asked earlier what his NGROUPS_MAX was >>>> set to, as I expect that's where he was seeing the 16-group limit. I've >>>> seen it anywhere from 8 to 65536, though on most modern Unixes I >>>> deal with its at least 20. Anyway you want to get that limit using >>>> sysconf, something like: >>>> >>>> long ngroups_max = 8; >>>> ngroups_max = sysconf(_SC_NGROUPS_MAX); >>>> if( ngroups_max < 0 ) >>>> ngroups_max = NGROUPS_MAX; >>>> >>>> Also, just as an FYI, under Linux you don't need to be superuser. You >>>> just have to have the CAP_SETGID capability. And that can be set >>>> on the executable file using the setcap command. (But for this case, >>>> it doesn't matter much anyway because you'll be usually be root) >>>> >>>> >>>> Another idea is to restrict the groups that can get set by matching >>>> them with the total list as returned by the getgrouplist() call. I'm not >>>> too sure on how portable that last on is though, or if it suffers from >>>> the NGROUPS_MAX limit. >>>> >>>> >>>>> Thus, feasibly one could allow 'groups' parameter of WSGIDaemonProcess >>>>> to take a comma separated list, also allowing 'a,' to indicate single >>>>> group, and use this function to override the group vector. >>>>> >>>>> Now, is there any reasonable use of this outside of this persons one >>>>> case to justify making such an enhancement. >>>> >>>> I don't see a huge need for it at the moment, but it could be useful. >>>> Mainly to allow for better sand-boxing in some cases. >>>> >>>> I've actually been toying with the idea of getting different wsgi daemon >>>> groups to run with different SELinux security contexts ... but that is >>>> definitely very specialized. .... and the group permissions thing is >>>> much easier for most people to understand and administer. >>> >>> Okay, this is how it can be done. >>> >>> If the existing 'group' option isn't used, then it currently takes on >>> the value of Group directive for Apache, which is usually something >>> like 'www', 'www-data', 'wwwserv' etc. >>> >>> If it is supplied, then the argument to the option becomes the group >>> instead. >>> >>> In both cases that group is currently used to set the effective group >>> ID of the process using setgid(). >>> >>> At the moment, what also happens is that the group vector for the >>> process is set using initgroups(). >>> >>> Thus, is set to the effective group ID, plus the first NGROUPS_MAX-1 >>> entries in the /etc/groups file for that user. >>> >>> What can do is provide a new option called 'supplementary-groups'. >>> >>> This can be set to be a comma separate listed of group names with >>> these being used in place of the list of groups taken from /etc/group >>> by initgroups(). >>> >>> So, instead of calling initgroups(), instead do what initgroups() >>> does, which is called setgroups() directly, but with group vector >>> constructed from value for 'group' and the list of groups supplied by >>> 'supplementary-groups'. >>> >>> All up, pretty easy to implement. >>> >>> Question now is whether OP is still around and reading the thread and >>> will use it if implemented in trunk of subversion repository. :-) >> >> Implemented in subversion trunk. >> >> Only problem is that on MacOS X it doesn't seem to do what it is supposed to. >> >> Don't know whether I am doing something obviously wrong which I cant >> see, or whether on MacOS X you are meant to do this differently, which >> wouldn't expect to be the case. >> >> In short, if I call os.getgroups() in a hello world Python WSGI >> application and dump that back to browser, it always shows what are >> the groups associated with the user and not those I specify with the >> supplementary-groups option. >> >> So, although have shown from debugging that setgroups() rather than >> initgroups() is called and input is correct, doesn't seem to work. >> >> Got a few more checks to do, but if curious you can play with it and >> maybe spot what I am doing wrong. > > Bizarre. > > MacOS X 10.6 (Snow Leopard) works differently to MacOS X 10.5 (Leopard). > > For the test program: > > import os > > print os.getgroups() > os.setgroups([1]) > print os.getgroups() > > On 10.5 I get: > > home:~ grahamd$ sudo python /tmp/testgroups.py > [0, 1, 2, 8, 29, 102, 3, 9, 4, 101, 5, 80, 20] > [1] > > Yet on 10.6 I get: > > [0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2, 1] > [0, 101, 204, 100, 98, 80, 61, 29, 20, 12, 9, 8, 5, 4, 3, 2, 1] > > So, setgroups() does nothing at all, thus why all my changes in > mod_wsgi weren't working. > > That or getgroups() is lying, which seems to be suggested by: > > http://bugs.python.org/issue7900 > > Although this an issue in Python bug tracker, it relates to underlying > operating system functions. > > Looks like I will need to go test the mod_wsgi changes on MacOS X 10.5 > (Leopard).
Yeah crap. The mod_wsgi code works fine under 10.5 Leopard. Under 10.6 Snow Leopard issue seems to be that system getgroups() doesn't work as one expects, but that setgroups() should still do what one expects in setting up the required groups. Would just have to get trick to test that theory, something don't have time for now. So, hopefully the OP will try giving the code in subversion trunk a go and see if it solves there problem. Graham -- You received this message because you are subscribed to the Google Groups "modwsgi" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/modwsgi?hl=en.
