Opened 5 years ago
Closed 2 years ago
#41039 closed defect (invalid)
Installing MacPorts on Mavericks Renames "staff" Group To "macports"
Reported by: | roberthuston@… | Owned by: | macports-tickets@… |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | base | Version: | 2.2.1 |
Keywords: | Cc: | cooljeanius (Eric Gallager) | |
Port: |
Description (last modified by ryandesign (Ryan Schmidt)) ¶
After upgrading to Mavericks, I installed MacPorts 2.2.1 using the "Mavericks" version of the installer. Today, when doing an "ls -l" in Terminal, I noticed that my default user group now says "macports" instead of "staff." However, when I look at the gid that is allocated to the "macports" group, it is indeed the value 20 that is normally associated with "staff." Somehow the MacPorts installation has hijacked the "staff" name. How can I get it restored to its proper name?
A listing of my /etc/group file still has
staff:*:20:root
as one of the entries, and there are no "macports" entries. So where is this remapping of the "staff" into "macports" happening?
Change History (14)
comment:1 Changed 5 years ago by ryandesign (Ryan Schmidt)
Component: | ports → base |
---|---|
Description: | modified (diff) |
comment:2 Changed 5 years ago by roberthuston@…
Additionally, when I plug in my Time Machine drive, the group name changes back to "staff." This may be a Mavericks thing, but it seems odd that everything behaved until I installed MacPorts.
I will look at the open directory stuff and report on what I find.
Changed 5 years ago by roberthuston@…
Attachment: | macports Group.png added |
---|
Changed 5 years ago by roberthuston@…
Attachment: | Staff Group.png added |
---|
comment:3 Changed 5 years ago by roberthuston@…
I just attached two window captures of both the "macports" group and the "staff" group. You can see that they both share the same ID of 20. Is it safe to delete the macports entry?
comment:4 Changed 5 years ago by roberthuston@…
I ran "sudo odutil reset cache" and things still showed up as "macports." I then renamed /opt/local to /opt/_local and then thing showed up as "staff" again. I've renamed /opt/_local back to /opt/local and so far things are still correctly at "staff." I then logged out and back in, and things are still correctly at "staff." So perhaps the resetting of the cache was what did it and the renaming of /opt/local was coincidental. We'll see how things behave over time. Not sure how much real "data" I can provide on this and so I'm probably not much help to anyone who could identify "the bug." But you may want to file it away just in case someone else runs into the same issue.
Sorry if I wasted anyone's time.
comment:5 Changed 5 years ago by roberthuston@…
Digging more into the installer targets of the MacPorts project Makefile, the installation process creates a MacPorts user and a macports group. The user ID will be the next available ID, but the group ID ends up being 20, which is also the same ID used for staff.
Is this a misuse of gid's or is it the correct UNIX way. Either way, I sometimes see things as "staff" and other times as "macports," usually after running the port command itself.
comment:6 Changed 5 years ago by roberthuston@…
OK, I think this can be regarded as a mangled GID issue. My user account was migrated to a new MacBook Pro in 2011 from an old MacBook Pro that was initially brought to life in 2006. Somewhere along the line, a macports group had gotten created with the same GID as "staff" (i.e., GID=20). Looking at the details in the MacPorts Makefile, I was able to fix the GID values to what they would have been had they been created by the current installer, and things appear to be working much better.
I've installed, uninstalled, and reinstalled MacPorts many times over the years, but was never aware of the "macports" user and group entities. Details on their removal should probably be added to the "Uninstall" instructions on the MacPorts Guide.
Hope this information helps somebody else out.
comment:8 follow-up: 9 Changed 5 years ago by adrian@…
I just ran into this issue too - quite shocking to see all your files owned by group macports, but doesn't seem to cause great problems.
I fixed this by deleting the macports user and group using /System/Library/CoreServices/Directory Utility.app and then running a small script produced from the macports pkg installer's postinstall script.
Save this as create-macports-user-group.sh and then run with "sudo ./create-macports-user-group.sh"
#!/bin/bash # Abstraction variables: DSCL=/usr/bin/dscl RUNUSR=macports # create the user to use for privilege dropping DSEDITGROUP=/usr/sbin/dseditgroup if ! ${DSCL} -q . -read /Groups/${RUNUSR} > /dev/null 2>&1 ; then echo "Creating group \"${RUNUSR}\"" ${DSEDITGROUP} -q -o create ${RUNUSR} fi if ! ${DSCL} -q . -list /Users/${RUNUSR} > /dev/null 2>&1 ; then echo "Creating user \"${RUNUSR}\"" NEXTUID=501 while [[ -n "`${DSCL} -q /Search -search /Users UniqueID $NEXTUID`" ]]; do let "NEXTUID=NEXTUID+1" done ${DSCL} -q . -create /Users/${RUNUSR} UniqueID $NEXTUID # These are implicitly added on Mac OSX Lion. AuthenticationAuthority # causes the user to be visible in the Users & Groups Preference Pane, # and the others are just noise, so delete them. # https://trac.macports.org/ticket/30168 ${DSCL} -q . -delete /Users/${RUNUSR} AuthenticationAuthority ${DSCL} -q . -delete /Users/${RUNUSR} PasswordPolicyOptions ${DSCL} -q . -delete /Users/${RUNUSR} dsAttrTypeNative:KerberosKeys ${DSCL} -q . -delete /Users/${RUNUSR} dsAttrTypeNative:ShadowHashData ${DSCL} -q . -create /Users/${RUNUSR} RealName MacPorts ${DSCL} -q . -create /Users/${RUNUSR} Password \* ${DSCL} -q . -create /Users/${RUNUSR} PrimaryGroupID $(${DSCL} -q . -read /Groups/${RUNUSR} PrimaryGroupID | /usr/bin/awk '{print $2}') ${DSCL} -q . -create /Users/${RUNUSR} NFSHomeDirectory ${PREFIX}/var/macports/home ${DSCL} -q . -create /Users/${RUNUSR} UserShell /usr/bin/false fi if [[ $(sw_vers -productVersion | /usr/bin/awk -F . '{print $2}') -eq 4 ]]; then GID=$(${DSCL} -q . -read /Groups/${RUNUSR} PrimaryGroupID | /usr/bin/awk '{print $2}') if [[ "$(${DSCL} -q . -read /Users/${RUNUSR} PrimaryGroupID 2>/dev/null | /usr/bin/awk '{print $2}')" != "$GID" ]]; then echo "Fixing PrimaryGroupID for user \"${RUNUSR}\"" ${DSCL} -q . -create /Users/${RUNUSR} PrimaryGroupID $GID ${DSCL} -q . -create /Users/${RUNUSR} RealName MacPorts fi fi if [[ "$(${DSCL} -q . -read /Users/${RUNUSR} NFSHomeDirectory)" = "NFSHomeDirectory: /var/empty" ]]; then echo "Updating home directory location for user \"${RUNUSR}\"" ${DSCL} -q . -create /Users/${RUNUSR} NFSHomeDirectory ${PREFIX}/var/macports/home fi
After that the macports user and groups PrimaryGroupID was 502, instead of 20.
comment:9 Changed 5 years ago by roberthuston@…
Replying to adrian@…:
...
After that the macports user and groups PrimaryGroupID was 502, instead of 20.
I did this manually a few weeks ago by looking at the MacPorts makefile, and this definitely cleared things up. My machine's user account has been migrated over the years from OS X Panther. I suspect the macports user account and group got created a long time ago from an early form of MacPorts and ended up with a group ID of 20, which is also used for staff. For some reason, Mavericks resolves the duplicate ID dilemma differently than previous versions of OX X and so I was never really aware of it. But once I cleaned up the user ID and group ID so that they were unique, things now behave themselves.
comment:10 follow-up: 11 Changed 4 years ago by adrinux@…
That thing where you find something wrong, search and find out you've both had the problem before and posted a solution :/ Just discovered macports is once again set to use group id 20 on my box.
dscl -q . -read /Groups/macports AppleMetaNodeLocation: /Local/Default GeneratedUID: 00878EA3-A881-47A2-BDB1-9258F20022C2 PrimaryGroupID: 20 RecordName: macports RecordType: dsRecTypeStandard:Groups
This time I just changed the macports GID instead. List all IDs so we can choose one that's not in use
dscl . -list /Groups PrimaryGroupID
Then I changed macports id from 20 to 502, and changed the macports users PrimaryGroupID to the same number, 502 in my case.
sudo dscl -q . -create /Groups/macports PrimaryGroupID 502 sudo dscl -q . -create /Users/macports PrimaryGroupID 502
comment:11 Changed 3 years ago by alexreg@…
Replying to adrinux@…:
That thing where you find something wrong, search and find out you've both had the problem before and posted a solution :/ Just discovered macports is once again set to use group id 20 on my box.
dscl -q . -read /Groups/macports AppleMetaNodeLocation: /Local/Default GeneratedUID: 00878EA3-A881-47A2-BDB1-9258F20022C2 PrimaryGroupID: 20 RecordName: macports RecordType: dsRecTypeStandard:GroupsThis time I just changed the macports GID instead. List all IDs so we can choose one that's not in use
dscl . -list /Groups PrimaryGroupIDThen I changed macports id from 20 to 502, and changed the macports users PrimaryGroupID to the same number, 502 in my case.
sudo dscl -q . -create /Groups/macports PrimaryGroupID 502 sudo dscl -q . -create /Users/macports PrimaryGroupID 502
This problem just happened for me, disturbingly. Can the MacPorts maintainers please fix this in their release?
The fix you suggested seems to work, however. Thanks.
comment:12 Changed 2 years ago by raimue (Rainer Müller)
Resolution: | → invalid |
---|---|
Status: | new → closed |
The problem here seems to be that a migration from one Mac to another created a macports
user with gid=20. This would be the fault of the software doing the migration, not MacPorts.
I'm not sure why this is happening, but to answer your question about where this is happening, read the top of the /etc/group file: