On Aug 9, 2011, at 9:02 AM, Les Mikesell wrote: > On 8/9/2011 10:44 AM, Craig White wrote: >> >>> There's probably a way to add apache to that group with a configuration >>> on the local machine so it doesn't have to query your ADS/NMB server. >>> Not sure about the details but the docs at http://samba.org/samba/docs/ >>> are invaluable. >> ---- >> I'm quite sure that if all the files are owned by the 'department_a' group and 'readable' by user apache as I have indicated, they should be with the given configuration, there's absolutely no need to do any mucking with local users or groups at all. >> >> The reality is that this machine will query AD/NMB server each time a non-local user does anything on this system (read or write) and the only thing that will lighten that load is something like NSCD (good luck with that - not always a great option with samba). > > Really? I thought samba would map a connection to a uid at connect time. ---- indeed it does but that doesn't mean that the system won't keep polling the authoritative account info source. ---- > >> There are two important features of what I proposed... >> - sgid means that all files/folders created within will always belong to department_a group > > You can also do a 'force group' in the samba config for a share instead > of or besides the sgid directory. ---- true but: 1 - force anything seems to be a little heavy handed 2 - using sgid means that anyone using a shell will also create files/directories with the same group - using 'force group' only has implications for samba connections. Using sgid encompasses all methods of access. ---- > >> - create mask 664& directory mask 775 means that each file& directory created - group will always get rw privileges and everyone else (ie user apache) has 'read' privileges. >> >> The only weakness of this theory as I see it, is that there very well may be files - perhaps config files that you wouldn't want anyone to be able to see and you probably will have to have some<Directory> restrictions in Apache's configuration to prevent web users from accessing them. > > There are also likely situations where the web server needs write > access, although those cases should be handled carefully or avoided > where possible. ---- indeed Craig