We're running a Mac OS 10.8.3 server using the File Sharing feature. We have both AFP and SMB sharing enabled.
When we change a user's permissions, their permissions are set properly when accessing the server via AFP, but when using SMB, their permissions are incorrect. As an example, we removed a user from a group, and while on AFP they are properly blocked, they can still access their old folders using SMB. I have confirmed it is not a caching issue, as new content within the blocked folders is also visible to them.
This is clearly a major security issue, but I have no idea how to fix it. I've tried enabling ACLs on SMB, but to no avail.
Any help would be appreciated!
NEW INFORMATION 3/28:
- Adding a user to a group DOES update permissions on the SMB share, and immediately. However, REMOVING the user from a group does NOT remove their permissions on SMB. In other words, a user retains any groups they've ever been in for the SMB share.
- If I change the permissions on a folder, everything updates immediately.
- Using SSH, I can confirm that the user's permissions are indeed updated properly in UNIX; if I remove them from the group, they no longer have access to those folders via SSH (or AFP).
So basically, the problem is removing a user from a group – it removes their permissions on the AFP share, but to SMB, it thinks the user is still in the group that they were removed from.
Best Answer
It looks to me that this is a caching issue, but caching of group memberships not files, and it's not just the SMB service. If I add someone to a group, then make an SMB or AFP connection to the server, or a Terminal session, or even log directly into the desktop on the server; then remove them from the group, the active session(s) seem to retain that group membership for as long as I tested (at least a few minutes).
The effects of this can be a bit strange. The retained group membership seemed to be linked to when a process was started; for example, I logged in to the desktop as a particular user, revoked their group membership, then opened Terminal -- at that point, Finder could still access files based on the former group, but the Terminal session couldn't.
New sessions might get the group membership, but only if they started within a few seconds of the group membership being revoked. So I think there are actually multiple layers of membership caching...