You can make a difference in the Apple Support Community!

When you sign up with your Apple Account, you can provide valuable feedback to other community members by upvoting helpful replies and User Tips.

Looks like no one’s replied in a while. To start the conversation again, simply ask a new question.

jkbull Author

Level 1

86 points

Does 10.9.3 make /Users insecure by setting permissions to 0777?

The 10.9.3 update seems to sometimes change the permissions on /Users from 0755 to 0777, allowing any user to make modifications to the folder. There are reports here and here. I found out about this because Tunnelblick checks permissions of various system folders that it uses (and their parent folders) and refuses to run if they are not secure.

There are conflicting reports about whether or not Disk Utility's "Repair Permissions" will repair this. It may repair the permissions but then the incorrect permissions reappear after a computer restart.

Is anyone else seeing this behavior? It does not happen on a clean install of 10.9.2 followed by the 10.9.3 update, so it probably involves some third-party software. If people list their third-party apps and kexts, especially apps that launch on startup or login and kexts that are loaded when this problem occurs, it might help track down the problem.

OS X Mavericks (10.9.3)

Posted on May 16, 2014 4:00 AM

Top-ranking reply

Tim_Doe

Level 1

19 points

Posted on May 16, 2014 6:03 AM

Same here. Permissions on /Users are set to 777 after the OS X 10.9.3 upgrade (and I believe the group should also be wheel?!). While "Disk Utility" detects and repairs this, permissions are reset to 777 after each reboot:

drwxrwxrwx@ 7 root admin 238 15 May 20:14 Users

After each and every reboot, "Disk Utility" finds this:

Verifying permissions for “Macintosh HD”

Permissions differ on “Applications/Safari.app/Contents/Resources/Safari.help/Contents/Resources/inde x.html”; should be lrwxr-xr-x ; they are -rwxr-xr-x .

Permissions differ on “Users”; should be drwxr-xr-x ; they are drwxrwxrwx .

Permissions differ on “Users/Shared”; should be drwxrwxrwt ; they are drwxrwxrwx .

Permissions verification complete

I do not think my system is heavily modified:

Tims-MacBook-Pro:~ tim$ kextstat | grep -v com.apple

Index Refs Address Size Wired Name (Version) <Linked Against>

Tims-MacBook-Pro:~ tim$ ls -l /Library/LaunchDaemons/

total 32

-rw-r--r-- 1 root wheel 462 18 Apr 15:46 com.adobe.fpsaud.plist

-rw-r--r-- 1 root wheel 568 2 Apr 2012 com.microsoft.office.licensing.helper.plist

lrwxr-xr-x 1 root wheel 103 18 Feb 20:59 com.oracle.java.Helper-Tool.plist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/com.oracle.java.Helper-Tool .plist

-rw-r--r-- 1 root wheel 486 22 Apr 20:59 com.oracle.java.JavaUpdateHelper.plist

Tims-MacBook-Pro:~ tim$ ls -l /Library/LaunchAgents/

total 8

lrwxr-xr-x 1 root wheel 104 18 Feb 20:59 com.oracle.java.Java-Updater.plist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/com.oracle.java.Java-Update r.plist

Tims-MacBook-Pro:~ tim$ ls -l /Library/LaunchDaemons/

total 32

-rw-r--r-- 1 root wheel 462 18 Apr 15:46 com.adobe.fpsaud.plist

-rw-r--r-- 1 root wheel 568 2 Apr 2012 com.microsoft.office.licensing.helper.plist

lrwxr-xr-x 1 root wheel 103 18 Feb 20:59 com.oracle.java.Helper-Tool.plist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/com.oracle.java.Helper-Tool .plist

-rw-r--r-- 1 root wheel 486 22 Apr 20:59 com.oracle.java.JavaUpdateHelper.plist

Tims-MacBook-Pro:~ tim$

View in context

42 replies

May 16, 2014 10:58 AM in response to jkbull

Hi,

on your machine which has still the /Users folder visible and the proper permissions, did you install the iTunes 10.2 update, too?

It seems this "bug" is not 10.9.3 update related but coming from iTunes 10.2 update.

On 1 machine with only the 10.9.3 udpate I have proper permissions and folder visibile. Once I installed iTunes 10.2 update -BOOM folder gone

and permission wrong...

Could you check please?

Thanks,

Message was edited by: Solitary_Satellite

May 16, 2014 11:00 AM in response to kevin_

Agreed that this might be a solution but I am not keen on explaning to my sister on how to chmod her Users folder 😢 I hope Apple will aknowledge and adress this issue rapidly.

kevin_

Level 4

1,561 points

May 16, 2014 11:08 AM in response to Solitary_Satellite

here are the step by step instructions. For both scenarios. If the Users folder is hidden or visible,

If the Users folder is visible. Start your computer while holding down the Command and R keys.

From the Utilities menu select Terminal.

In the Terminal type in the following commands:

cd /Volumes/Macintosh\ HD (or the name of your partition)

chmod 755 Users

chmod 755 Users/Shared

Quit the Terminal and restart your Mac.

===========================================================================

If the Users folder is not visible. Start your computer while holding down the Command and R keys.

From the Utilities menu select Terminal.

In the Terminal type in the following commands:

cd /Volumes/Macintosh\ HD (or the name of your partition)

chmod 755 Users

chmod 755 Users/Shared

chflags nohidden Users

chflags nohidden Users/Shared

Quit the Terminal and restart your Mac.

jkbull Author

Level 1

86 points

May 16, 2014 11:33 AM in response to Solitary_Satellite

On my machine that has /Users visible, I installed all updates from the App Store Updates tab via "Install All" (or something like that). It now shows that the following were installed:

OS X Update Combined 10.9.3

iTunes Version 11.2

Digital Camera RAW Comptability Update 5.05

and that no further updates are available.

I had never run iTunes ("About iTunes says it is 11.2 (115)"), so I launched it, accepted the terms and conditions, quit, launched it again, and then restarted (to see if somehow it is iTunes itself, or the iTunes Helper (which runs at login) doing this. But no, even after all that I still see /Users and it still has 0755 permissions -- that is, I don't have the problem.

But I noticed that I apparently updated using the combined updater. Maybe it is only the "delta" updater that produces this problem?

Can somebody with the problem try the combined updater (available at http://support.apple.com/kb/DL1746) and see if the problem is fixed by that? This wouldn't be the first time that a delta updater messed things up.

I'm also still interested in the output of "ls -l@e /" on an affected system.

May 16, 2014 11:37 AM in response to kevin_

Unfortunately logging in via the recovery console didn't work for me.

@jkbull - here is the output for the 'ls' you wanted to see:

$ ls -l@e / total 16445 drwxrwxr-x@ 94 root admin 3196 15 May 15:02 Applications com.apple.quarantine 67 0: group:everyone deny delete drwxrwxr-x 15 root admin 510 21 Nov 2011 Developer drwxr-xr-x+ 71 root wheel 2414 28 Apr 10:02 Library 0: group:everyone deny delete drwxr-xr-x@ 2 root wheel 68 25 Aug 2013 Network com.apple.FinderInfo 32 drwxr-xr-x+ 4 root wheel 136 23 Oct 2013 System 0: group:everyone deny delete lrwxr-xr-x 1 root admin 60 11 Apr 2010 User Guides And Information -> /Library/Documentation/User Guides and Information.localized drwxrwxrwx@ 7 root admin 238 23 Oct 2013 Users com.apple.FinderInfo 32 drwxrwxrwt@ 4 root admin 136 16 May 19:29 Volumes com.apple.FinderInfo 32 0: group:everyone deny add_file,add_subdirectory,directory_inherit,only_inherit drwxr-xr-x@ 39 root wheel 1326 28 Feb 08:52 bin com.apple.FinderInfo 32 drwxrwxr-t@ 2 root admin 68 25 Aug 2013 cores com.apple.FinderInfo 32 dr-xr-xr-x 3 root wheel 4263 16 May 19:24 dev lrwxr-xr-x@ 1 root wheel 11 23 Oct 2013 etc -> private/etc com.apple.FinderInfo 32 dr-xr-xr-x 2 root wheel 1 16 May 19:30 home drwxrwxrwt@ 2 root wheel 68 20 May 2013 lost+found com.apple.FinderInfo 32 -rwxr-xr-x@ 1 root wheel 8393936 18 Apr 07:03 mach_kernel com.apple.FinderInfo 32 dr-xr-xr-x 2 root wheel 1 16 May 19:30 net drwxr-xr-x@ 5 root admin 170 25 Mar 09:52 opt com.apple.FinderInfo 32 com.apple.quarantine 67 drwxr-xr-x@ 6 root wheel 204 23 Oct 2013 private com.apple.FinderInfo 32 drwxr-xr-x@ 62 root wheel 2108 16 May 09:37 sbin com.apple.FinderInfo 32 lrwxr-xr-x@ 1 root wheel 11 23 Oct 2013 tmp -> private/tmp com.apple.FinderInfo 32 drwxr-xr-x@ 12 root wheel 408 28 Apr 10:03 usr com.apple.FinderInfo 32 lrwxr-xr-x@ 1 root wheel 11 23 Oct 2013 var -> private/var com.apple.FinderInfo 32

I have just seen your other suggestion regarding combined vs. delta updater, will investigate that now.

jkbull Author

Level 1

86 points

May 16, 2014 11:41 AM in response to gaz_stephens

@Gaz_stephens - Thanks. In your list, the

drwxrwxrwx@ 7 root admin 238 23 Oct 2013 Users

com.apple.FinderInfo 32

means, unfortunately, that Apple hasn't just switched from securing /Users via permissions to securing it via ACLs -- there are no ACLs listed. So it is insecure with 0777 permissions.

May 16, 2014 12:32 PM in response to jkbull

Just to report back, I downloaded the full patch and ran the installer, machine took the patch rebooted etc but still having the same problem...😟

Any other ideas? Resetting the permissions each time isn't a big deal, just a pain (plus it defaults to insecure!) but happy to try other things.

kevin_

Level 4

1,561 points

May 16, 2014 12:49 PM in response to gaz_stephens

gaz,

As I posted earlier. You have to set the permissions when logged in as root for the changes to take effect over restarts. You can do this best when booting into the Recovery HD

May 16, 2014 1:06 PM in response to gaz_stephens

I confirm that the Combo update didn't work on my 3 machines.

May 16, 2014 1:07 PM in response to kevin_

FYI, opened terminal, went into su and chmoded but after reboot the permission reverted back to 777...

jkbull Author

Level 1

86 points

May 16, 2014 1:08 PM in response to gaz_stephens

I have a couple more ideas:

1. Try creating a new user (an Admin; I assume the user you are currently logging in as is an Admin). Make sure you have auto-login off, fix the permissions, reboot, and log in as the new user.

2. Maybe the "safe boot" isn't really safe. That is, maybe it does run non-Apple software. For example, if a third-party put plists in /System/Library/LaunchDaemons or /System/Library/LaunchAgents.

So it's worth doing

ls -l /System/Library/LaunchDaemons | grep -v com.apple

and

ls -l /System/Library/LaunchAgents | grep -v com.apple

and seeing what shows up. (I'm assuming "safe boot" loads them because they are in /System/Library, but I could be wrong.)

On my Mavericks system (which, again, does NOT have the problem), I see

$ ls -l /System/Library/LaunchDaemons | grep -v com.apple

total 16

-rw-r--r-- 1 root wheel 678 Sep 8 2013 bootps.plist

-rw-r--r-- 1 root wheel 672 Sep 8 2013 com.danga.memcached.plist

-rw-r--r-- 1 root wheel 574 Sep 8 2013 com.vix.cron.plist

-rw-r--r-- 1 root wheel 613 Sep 8 2013 exec.plist

-rw-r--r-- 1 root wheel 682 Sep 8 2013 finger.plist

-rw-r--r-- 1 root wheel 763 Sep 8 2013 ftp.plist

-rw-r--r-- 1 root wheel 246 Sep 8 2013 login.plist

-rw-r--r-- 1 root wheel 627 Sep 8 2013 ntalk.plist

-rw-r--r-- 1 root wheel 625 Sep 8 2013 org.apache.httpd.plist

-rw-r--r-- 1 root wheel 771 Sep 8 2013 org.cups.cups-lpd.plist

-rw-r--r-- 1 root wheel 1480 Sep 8 2013 org.cups.cupsd.plist

-rw-r--r-- 1 root wheel 489 Sep 8 2013 org.freeradius.radiusd.plist

-rw-r--r-- 1 root wheel 900 Sep 8 2013 org.isc.named.plist

-rw-r--r-- 1 root wheel 495 Sep 8 2013 org.net-snmp.snmpd.plist

-rw-r--r-- 1 root wheel 625 Sep 8 2013 org.ntp.ntpd.plist

-rw-r--r-- 1 root wheel 966 Sep 8 2013 org.openldap.slapd.plist

-rw-r--r-- 1 root wheel 585 Mar 23 2012 org.postfix.master.plist

-rw-r--r-- 1 root wheel 1284 Sep 8 2013 org.postgresql.postgres_alt.plist

-rw-r--r-- 1 root wheel 238 Sep 8 2013 shell.plist

-rw-r--r-- 1 root wheel 884 Sep 8 2013 ssh.plist

-rw-r--r-- 1 root wheel 260 Sep 8 2013 telnet.plist

-rw-r--r-- 1 root wheel 715 Sep 8 2013 tftp.plist

$ ls -l /System/Library/LaunchAgents | grep -v com.apple

total 8

-rw-r--r-- 1 root wheel 596 Sep 8 2013 org.openbsd.ssh-agent.plist

If you other items, maybe they are the problem.

May 16, 2014 1:10 PM in response to kevin_

Do you have "Find my Mac" activated?

It seems that it is in conjunction with iTunes 10.2 update + Find my Mac:

http://www.macobserver.com/tmo/article/hidden-users-folder-result-of-itunes-11.2 -and-find-my-mac-combination-not-1?utm_source=macobserver&utm_medium=rss&utm_cam paign=rss_everything

jkbull Author

Level 1

86 points

May 16, 2014 1:20 PM in response to kevin_

@Kevin - Can you double-check your results?

How can doing the chmod as root have a different result than doing the chmod with su?

The permissions are 0755 after either is done, and it's hard to believe that OS X "remembers" that it was done by root and keeps them, or by su and changes them back to 0777.

@Solitary_Satellite - I do not have Find My Mac activated. If you do, then maybe that's why we're getting different results. I will enable FMM and see what happens.

kevin_

Level 4

1,561 points

May 16, 2014 1:25 PM in response to jkbull

When you use su when setting chmod 755 the owner is your admin user name, where doing this as root it changes the owner to root which is the normal owner of the Users folder.

jkbull Author

Level 1

86 points

May 16, 2014 1:56 PM in response to kevin_

@kevin_ - I don't see that behavior.

The owner doesn't need to change to root, it already is root.

People aren't reporting a problem with the owner of /Users, only with the permissions.

And if I have

drwxrwxrwx@ 7 root admin 238 23 Oct 2013 Users

(which is what Tim_Doe and gaz_stephens had) and do

su chmod 0755 /Users

(which is what they did), I then have

drwxr-xr-x@ 7 root admin 238 23 Oct 2013 Users

Which is what I expect from chmod. I don't get

drwxr-xr-x@ 7 myadminusername admin 238 23 Oct 2013 Users

Which would be totally weird -- the chmod command should not change the owner, just the mode. And there's nothing on the chmod man page that indicates it does.

Does 10.9.3 make /Users insecure by setting permissions to 0777?