3

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.

jstm88
  • 757
  • 2
  • 9
  • 21
  • What client OS is in use and what authentication method is used? Are these Windows clients authenticating against AD? – joeqwerty Mar 26 '13 at 20:09
  • Active Directory isn't used, just basic user account authorization. The client is either Mac OS 10.8.3 or Windows 8 via SMB. (Mac OS X connects fine on both, but permissions over AFP/SMB are different). Both Windows and Mac show the same permissions when using SMB. – jstm88 Mar 26 '13 at 20:57
  • I'll work on reproducing this, in the mean time - what ACL are yo setting on the server side for a folder and how is a Mac client showing you the settings once the SMB mount is completed? – bmike Mar 27 '13 at 17:43
  • On one of the folders, I have the permissions as follows via the Server.app interface. Group1:read/write, Spotlight:custom, Owner:read/write, staff:none, Others:none. Permissions on the enclosing folder are: Group1:read Group2:read/write, Owner:read/write, staff:none, Others:none. The user I'm connecting with is in Group2 but not in Group1. In the meantime, it looks like permissions for the test user did in fact update. I'm definitely interested in if you're able to reproduce it though. I'll be doing some testing on my end as well to see if it's reproducible, and if so, what the delay time is. – jstm88 Mar 28 '13 at 16:31
  • Sorry, my bad. The permissions did NOT update, I was going off of bad information. They're still exactly like they were, and not correct. – jstm88 Mar 28 '13 at 16:57
  • New information added in the description regarding groups. – jstm88 Mar 28 '13 at 17:06
  • Have you managed to fix this? I can't believe it's 2013 and we're still debugging permissions. – unom Apr 02 '13 at 21:07
  • No, this still hasn't been resolved. I posted on the Apple forums as well, nobody responded – jstm88 Apr 04 '13 at 22:33

1 Answers1

1

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...

Gordon Davisson
  • 11,216
  • 4
  • 28
  • 33
  • Sounds plausible. However, we've rebooted the server since revoking the permissions, to no effect. Also, I'm curious if you have any insights into how to control the caching. I can confirm that AFP/SSH/login permissions are revoked properly, and AFP at least (I didn't test local login or SSH on this one) revokes permissions immediately, even during an active connection. – jstm88 Mar 29 '13 at 20:46
  • Issue is obsolete, so I'm accepting this answer for the heck of it. :) – jstm88 Jan 22 '14 at 16:50