Skip to end of metadata
Go to start of metadata

Background:

The ICTS Sysadmin team have discovered a seemingly undocumented bug in the NFS client included with Mac OSX 10.7 (Lion).  Users had reported that they were unable to access certain directories despite having full read/write permissions via their group membership.  The problem initially presented itself as being system-specific as the same user was able to access the directory on another similar machine, however over time other users began to experience similar problems with other directories.  The problem only affected certain users on certain machines with few obvious similarities to link occurrences of the problem.

 

Example of problem:

(Note: username and machine name have been obscured for security purposes)

[username@machine ~]$ ls /paulsen/MRx/PHD_120/

ls: : Permission denied

[username@machine ~]$ id

uid=10392(username) gid=9010(prog) groups=9010(prog),9005(user),33(_appstore),79(_appserverusr),80(admin),81(_appserveradm),204(_developer),9030(stdwkup)

[username@machine ~]$ ls -l /paulsen/MRx/

...

drwxrwx--- 49 otheruser stdwkup 49 Oct 6 01:05 PHD_120/

...

Notice, the user is a member of the 'stdwkup' group.  This group has full rwx permissions to the PHD_120 folder, yet when that user tries to access the folder they get "Permission denied"

 

Cause:

Through the use of Wireshark we were able to determine that due to an apparent bug in the NFS client on Mac OSX Lion, whatever group has the highest GeneratedUID does not get passed through NFS, but rather passes GID=0 (Creating another potential security issue outlined below).

 

Workaround:

In order to avoid the manifestation of this problem we have begun populating affected Mac workstations with a group named "FakeGroup" and forcing that group to have the highest possible GeneratedUID (FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF), we then add a group which all users are a member of (In our case the 'user' group) to the Nexted Group membership of FakeGroup.  By doing this the all users become a member of FakeGroup and this is the only group that is omited by NFS.

The command we use to accomplish this is:

dscl . create /Groups/FakeGroup GeneratedUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ; dscl . create /Groups/FakeGroup PrimaryGroupID 345678 ; dscl . create /Groups/FakeGroup RealName "Fake Group" ; uguid=$(dscl . read /Groups/user GeneratedUID | awk '{print $2}') ; dscl . create /Groups/FakeGroup NestedGroups $uguid

* Note, in the above command we are using the group called 'user' for a group that all users are a member of, and give the FakeGroup group a PrimaryGroupID of 345678.  These options may need to be modified depending on your environment.

 

Security Concern:

Our workaround does not address the concern that this Bug passes GID=0 in place of the omited group membership.  GID=0 is generally the ROOT group.  In our environment we do not use the root group for any permissions, so the risk is minimal, however in other environments where the root group is used this could create a significant security problem.

 

Puppet Code for Workaround:

Below is the code we added to our Mac puppet manifest to automatically push this to our systems.

exec {"fixMacNFSProblem_with_FAKEGROUP":

                command => 'dscl . create /Groups/FakeGroup GeneratedUID FFFFFFFF-FFFF-FFFF-FFFF-FFFFFFFFFFFF ; dscl . create /Groups/FakeGroup PrimaryGroupID 345678 ; dscl . create /Groups/FakeGroup RealName "Fake Group" ; uguid=$(dscl . read /Groups/user GeneratedUID | awk \'{print $2}\') ; dscl . create /Groups/FakeGroup NestedGroups $uguid',

                unless => 'dscl . read /Groups/FakeGroup',

        }

 

Labels
  • None