I've been picking at a similar problem for a while now, and I have two questions.
First, you said that the webserver will assert access control policies. I presume these policies are separate from filesystem permissions (I don't know of any way to have Apache processes run as a UID based on authentication credentials) - I'd be curious to hear how this is being done. Second, the only way that I know of for a user to write arbitrary files to a server is via WebDAV. How are you planning to do this? Or is this part of a workflow using CGI to do the actual disk i/o? BTW, if you wanted to roll your own, you could use inotify - a kernel based set of utilities to fire off tasks when the contents of a monitored directory changes. I set up a replication system using some scripts that push content that is scp'd to a particular directory... And you might also find the use of ACLs, if supported, can help, too. _KMP On 11 Nov 2011, at 13:28 , Ian Stokes-Rees wrote: > > > On 11/11/11 12:39 PM, Bill Bogstad wrote: >> You might look into doing a "chmod g+s user-top-directory". This will cause >> the group of any files/directories created in that directory to be set to >> the group of the user-top-directory rather then the group of the process. If >> users' default umasks are set to 0007 as you suggest, this will probably >> work for you. The problem with this is that you might not want the users to >> be in the "webserver" group (otherwise they would be able to read other >> people's files). As a result, the users won't be able to make a top level >> directory with the appropriate group setting themselves. If you create the >> top level directory for them ahead of time (probably required for webserver >> access), then they will probably never need to do this. > > I think I've talked about trying this before and then didn't move forward > with it. This would be a great solution, and we can certainly create these > directories in advance (in fact, at account creation time), and set ownership > policies appropriately. I'll need to understand the semantics of u+s and g+s > to see if there are ways a user can "break out" of the setting in a way that > would impact others negatively (their problem if they screw themselves up, > but we can't have them accessing other users data or the "core" web-server > data). > > The think the idea would be: > > for u in /home/*; do > b=`basename $u` > mkdir $u/portal_data > chown -R apache:$b $u/portal_data > chmod -R u+rwX,g+rwXs,o-rwX $u/portal_data > done > > So when the webserver (process user apache) writes files to > /home/peterpan/portal_data/foo/bar then the ownership will be: > > apache:peterpan rw-rw---- > > Then peterpan can ssh into the system and still read these files in his home > directory, but he can't read files in /home/captainhook/portal_data/zip/zap. > ... K. M. Peterson, Boston http://kmpeterson.com/resume 40 Stanton Road Contact information, calendar, Brookline, MA 02445-6839 LinkedIn, Twitter, IM, Skype: Phone: +1 617 731 6177 http://kmpeterson.com/contact _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
