On Sunday 24 June 2001 16:15, Jeff S Wheeler wrote: > Also, stock 2.4.x series kernel limits supplementary groups to 32.
Good point! > There would be a per-process penalty for increasing that limit. You > could patch apache to include the supplemental groups when it forks > children (if it does not do this already..), but overall that is a bad > solution. Such a patch would require that Apache keep root privs all the time. Would you REALLY want this? > If your users' data really can't be world-readable, your remaining > option is to run seperate httpd's for customers with these large > privacy concerns. Note that most of the time, though, your customers > just don't want people copying their whole directory structures and > stealing content whole-sale. This can be accomplished by other means, > anyway, but you can give yor customers some comfort by simply > instructing them to set all their directories with permissions o-r. You can configure the FTP server and other ways of uploading content to specify the permissions for them (customers will forget). Separate web server instances is a really bad idea, it's a PITA to manage. > Note that CGIs/SSIs will be a security concern for you. You had better > use suEXEC or something else such that customers cannot execute their > CGI programs as the user/group apache's children run as, if you rely on > that for your privacy/security mechanism... suexec and cgiwrap are both good solutions to this problem. -- http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark http://www.coker.com.au/postal/ Postal SMTP/POP benchmark http://www.coker.com.au/projects.html Projects I am working on http://www.coker.com.au/~russell/ My home page
