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