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
_______________________________________________
CentOS mailing list
CentOS@xxxxxxxxxx
http://lists.centos.org/mailman/listinfo/centos
