Take the 2-minute tour ×
Server Fault is a question and answer site for professional system and network administrators. It's 100% free, no registration required.

Hoping someone can explain what is probably fairly obvious...but confuses me.

Imagine two users with admin privileges on our server (Mac OS X Server 10.5). Call them joe & bob.

both users are members of these groups:

 Staff       Group ID: 20
 Workgroup   Group ID: 1025
 Admin       Group ID: 80 (assuming "[X] Administer Server" in Workgroup Manager sets this)

Shared folder "devfolder" has sharing set as so:

POSIX:

 Owner: joe     read & write
 Group: admin   read & write
 Other          no access

ACL:

 Workgroup  Allow  Read & write

Question is why when looking at same folder does the ownership appear to change depending on who's doing the looking?!? Both looking at same folder on the server:

From Joe's perspective:

xserve:devfolder joe$ ls -l
drwxrwxr-x   6 joe  workgroup    204 May 20 19:32 app
drwxrwxr-x   9 joe  workgroup    306 May 20 19:32 config
drwxrwxr-x   3 joe  workgroup    102 May 20 19:32 db
drwxrwxr-x   3 joe  workgroup    102 May 20 19:32 doc
drwxrwxr-x   3 joe  workgroup    102 May 20 19:32 lib

And from Bob's perspective (folder mounted on his machine via AFP):

bobmac:devfolder bob$ ls -l
drwxrwxr-x   6 bob  _bob    264 May 20 19:32 app
drwxrwxr-x   9 bob  _bob    264 May 20 19:32 config
drwxrwxr-x   3 bob  _bob    264 May 20 19:32 db
drwxrwxr-x   3 bob  _bob    264 May 20 19:32 doc
drwxrwxr-x   3 bob  _bob    264 May 20 19:32 lib

Now if Bob connects to server via SSH then his output is identical to Joe's, as expected.

Can anyone tell me what the client is doing in this case and what should be expected when bob creates or updates files in this folder? What tools do I have to better understand this from the command line? Is this normal? Perhaps a "cleaner" way that wouldn't be confusing with "bob _bob"?!?

share|improve this question
    
How is Joe accessing the files? –  Clinton Blackmore May 22 '10 at 1:01

2 Answers 2

up vote 1 down vote accepted

AFP uses a permission model that is quite different from NFS. Clients connect using their credentials, and then file access is controlled by the server. In some cases, "Privilege Mapping" occurs, which is the phenomenon you're describing.

Benefits

  1. Much more secure than traditional NFS
  2. Very simple model and is ideal for a client that only ever has a single user logged in

Drawbacks

  1. Two users on the client can't simultaneously access the same mounted AFP filesystem as themselves. The best they can do is both access the filesystem with the permissions of the user that first mounted it (and even this would require client root for the other user)
  2. The permissions reported are not the "real" permissions from the perspective of the server

That drawback #2 is fixed in Snow Leopard 10.6. The rest of the implications of the security model still apply, but somehow the client knows to report the "real" permissions and not just the "effective" permissions as it had done before.

More information at:

share|improve this answer
    
Answer is not complete. It explain the HOW part but not the WHY? –  unmircea Apr 2 '13 at 21:08

I think that when you have direct access to all the files, you get the real permissions on them. When you mount it over AFP, it seems to show, shall we say, local permissions. (Possibly it has no idea who the other users on the remote system are, and just determines if you have read and write access to a file, and gives you ownership if you do, and doesn't show you if you don't.)

If bob modifies a file, I think you'll find that the permissions stay the same, as viewed from the server. I'm really not sure what happens when he creates a file. I suspect that the ownership attributes will match the credentials used to gain access to the AFP share.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.