On Fri, Nov 11, 2011 at 11:20 AM, Ian Stokes-Rees <[email protected]> wrote: > Hi experts, > > I'm in a situation where I need on-disk user data to be accessible by a > webserver process but also by the owners when they ssh into the system. My > initial ambitious plan for this was to have a "mirror" group for every user > that contained the user and also the web server daemon user. With careful > management of who created data and where it was created this looked like it > was going to work -- the webserver would assert access control policies so > the data could only be accessed by the owning user when coming in through > the web interface, and the user when ssh'ed in to the system could see all > their data but not that of other users. NFSv3 and its 12 (or 16?) group > membership limit meant this didn't get me very far in the end. > > I'm now wondering if an alternative might be to have all this "dual-access" > data owned by "joeblogs" (user) and "webserver" (group) (or vice versa), > with a default umask of "u=rwx,g=rwx,o=" (0007). No users would be in the > "webserver" group, and the webserver user wouldn't be in the joeblogs > group. The complexity here: how to (easily/practically) get the user and > webserver to create files with appropriate ownership. > > Does anyone have any thoughts or experience with this kind of problem?
Yeah. It's painful. :-) 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. Oh, I've never done anything with them myself; but you might want to look into what can be done with Access Control Lists. The downside is that your fileservers/applications/backup system may or may not work with them. But that's just me being worried, no specific problems to report. Bill Bogstad _______________________________________________ bblisa mailing list [email protected] http://www.bblisa.org/mailman/listinfo/bblisa
