10.4 AFP Group Permissions

We discovered this group permission issue this weekend and have been reading this thread with interest. We have decided to use the ACL permissions model and make things work NOW. This new permissions model looks good to us and so far is working fine.

I do think Apple might post a Knowledge Base article to tell people who to setup ACLs as work around the Group Permission issue with note that 10.4.2 will address the issue. Just a thought.

Thanks Gerrit,

macfixit.com ran the story I posted to them. I hope Apple wakes up and releases a fix asap.

have a nice day
Rob

Here's an update...

I have had luck using ACLs to supplement POSIX permissions, mostly to get the inheritance provided by same.

This is my procedure...

For a share point with read/write access to everyone (although the owner and group entries can be different):

owner - root, read & write
group - admin, read & write
everyone - read & write

ACL entry for "Users" (staff, GID 20) can: do all Read, do all Write, Inheritance to all descendants

Thus, all registered users (staff) get inherited read & write via the one ACL entry.

Also, the group Everyone (GID 12) and Authenticated Users (GID 37) are useful when creating ACL entries to mimic the everyone POSIX access level. These groups may be more powerful than staff, because if you change one user's primary group from staff to something else (and don't make that user a member of the staff group), staff no longer represents "all users". In POSIX access, staff is usually a primary group for all standard users except guests and system service users. (However, 10.3 client 10.4 client generate a new group for each new user: primary group gerrit corresponds to user gerrit.) Perhaps Authenticated Users and Everyone are "smart groups"... anyone have any experience with them?

This works fine, with these observations:

1. Tiger clients will show ACL information in their Finder Info windows when users mount the volume via Connect to Server.

2. Panther clients and Tiger clients that mount the share point via an automount record will show fake POSIX information in their Info windows. Access still respects the ACLs, though.

Often an example file appears to have received default umask permissions (755 for folders, 644 for files) but the owner appears to change (from the client's perspective) to match the user who has connected. In the Finder's Info windows, you may see "nobody" is the owner, but an "ls -l" in the Terminal will show the connected user as the owner.

It appears to be a side effect of the ACLs, although Finder Info windows should show when ACLs are used instead of an incorrect owner.

3. For automounts, both Tiger and Panther clients will mount via Guest access then switch access to the currently logged in user. Open Terminal and type mount to see which user is listed for the automounts. (Server Admin may still list <Guest> for static automounts.)

The only exception that I've found is the /Network/Library in Tiger clients. The user that appears to always mount that is security_agent, not the current user, which was the case in Panther. (Still, Server Admin shows <Guest>.) This is important if you want inheritance on some /Network/Library items, as we now have to know the user or group to specify inheritance like an access mode (instead of a permissions model.)

Also, the group Everyone (GID 12) and Authenticated Users (GID 37) are useful when creating ACL entries to mimic the everyone POSIX access level.

How do you get these groups in an ACL?
In WGM 10.3 you were able to see al system users and groups. In WGM 10.4 only the admin and staff group are added to the list when 'Show system users and group' is selected in the view menu.

Thanks in advance.

Is this an attempt by Apple to create a checkout system of sorts?

To see these the Everyone and Authenticated Users groups, you need to look in the server's local directory node (/NetInfo/DefaultLocalNode).

In the Sharing section of Workgroup Manager:

1. Select the share point, then click the Access tab.
2. Click the Users & Groups button.
3. In the Users & Groups drawer that appears, look at the top. You'll see a pop-up menu indicating the directory you're viewing. Click that and choose Local.

Apple has acknowledged that the Inherit Permissions model via POSIX access does not work in Mac OS X Server 10.4 and 10.4.1. Here's the KBase article:

http://docs.info.apple.com/article.html?artnum=301601

So, our efforts have not gone unnoticed. Keep pushing for a fix in 10.4.2.

--Gerrit DeWitt
Apple Certified System Administrator

Thanks that's what I was looking for.

By the way I try to use only ACL an put all POSIX permissions on none. The problem is new files and folders than get rw/r/r permissions. Is there some way to force POSIX permissions to none or make the services ignore POSIX permissions?

I guess you can put 'Everyone' in the ACL allowing noting (custom), to make POSIX permissions irrelevant.

Thanks in advance.

We have the same issue with 10.3.9 server and 10.4.1 clients using the "inherit permissions from parent"-flag

Our solution is to change permissions on servers sharepoint as follows:

chown -R root /path to sharepoint/
chmod -R 2770 /path to sharepoint/

Now TigerClient can generate a folder with the wanted group permissions.
rwxrws---

Andreas

I can confirm that Andeas' solution above appears to work.

I have yet to implement it on the active sharepoint (that's for tonight) but it was tested on a new test sharepoint OK. I created a folder at the top level called "test"... then...

sudo chown root:mygroup test

This sets owner to 'root' and group to 'mygroup'. Note that it appears necessary for the owner to be root - it did not work as any other user. If you were applying it to an existing sharepoint (as per Andreas' post) then you only need the initial 'root' owner as the existing group owner will remain the same. Then I ran...

sudo chmod 2775 test

This sets the folder permissions to drwxrwsr-x, i.e. read permissions for 'others' which is our own preference rather than 'none'. I then shared this via WM with permissions set to "inherit".

All users (10.3 & 10.4, local & network logins) can now create folders inside the test one - no errors.

Before I implement it I will need to fill in some gaps in my knowledge about the knock-on effect of using the 'Set-Group-id-On-Execution' bit (the 2000 part of the 2775) and maybe Andreas (or anyone else) can explain something more about this...

Also, Andreas seemed to suggest that new folders will inherit the rwxrws--- (in his case) permissions of the parent but in my own case the "s" bit did not inherit down from the parent - new folders show in a listing as drwxrwxr-x with owner as creator and group as "mygroup".

Hopefully this will fix things until Apple come up with something, so thanks, Andreas, for the pointer and dutifully recc'd!

Andreas, David:

I tried this out, applying sudo chown root:test1 /Volumes/Secondary/Test1, followed by sudo chmod 2770 /Volumes/Secondary/Test1 on a Tiger (10.4.1) server we're testing, then crossed my fingers, hoping for the best.

I then logged in from a Panther client (10.3.9) as User1, created a new folder and a new file. Both showed permissions (from the client) as rw(x), r--,r-- where the owner was User1 and group was test1.

No joy in mudville. Can this be applied to an existing folder structure, or do I have to start from scratch?

- Andrew

p.S. Checking permissions from the server showed the same thing: rw(x),r--,r-- where the owner is User1 and the group is test1.

p.p.S. I gave each of you a vote just on the principle that someone out there is trying to resolve this thing. It may not have worked for me (yet?), but maybe it'll work better for others.

I'm stilll runing 10.3.9, so I'm not having many permissions problems.

If Andreas's solutions does indeed work for 10.4, wouldn't this indicate a problem with the System setting the Sticky Bit for Directories?? For those that know UNIX better than I, is there a way to test this?

Hi all:

I haven't tried using Automator yet, and my terminal skills are limited, but has anyone thought about a folder action that would trigger a cron job to set folder permissions whenever a new file or sub-folder is created? Will automator launch a cron job, or would a folder action have to be launched by Applescript?

- Andrew

"It's not the stupid question I'm afraid of asking, it's the stupid answer I'm afraid of giving."

Hi Andrew,

I think there has been a confusing change of topic towards the end of this thread. It started as permissions problems on a Tiger server (as per your own), and then someone added in a similar problem between a Panther server and a Tiger client. Andreas's and my posts were in response to the latter problem where the server is still at Panther but a Tiger client has been introduced.

I'm going to have a look at other threads to see if there is one more suitable for our situation - maybe start a new one clearly titled.

-david

I found a specific thread relating to 10.3 Server and 10.4 Clients and copied the above posts to it. Probably best if any discussion relating to 10.3 Server and 10.4 Clients takes place there...

Stephane Laroye, "AFP goup permissions not working correctly with 10.4 client" #1, 04:17pm May 13, 2005 CDT

-david