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). 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.
