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