RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]

Brent Christian brent.christian at oracle.com
Thu Sep 5 21:30:24 UTC 2013

Please review my changes for 7199674

This improves how Java .app bundles work when they've been signed for 
the Mac App Sandbox.  Specifically, it changes how the user.home system 
property is set.

For apps signed for the App Sandbox, user.home will point to an 
accessible location within the App's sandbox container.  (If not signed 
for the App Sandbox, user.home still points to the user's home directory).

This is in line with how Mac sandbox-ed apps are expected to work (they 
are not permitted access to a user's "real" home directory).  For 
reference, an overview of the Mac App Sandbox is at [1], and this 
specific point comes from [2]:

"If you are using a POSIX function such as getpwuid to obtain the path 
to the user’s actual home directory from directory services (rather than 
by using the HOME environment variable), consider instead using a Cocoa 
or Core Foundation symbol such as the NSHomeDirectory function. By using 
Cocoa or Core Foundation, you support the App Sandbox restriction 
against directly accessing the user’s home directory."

I have confirmed that my change works as expected under the Mac App 
Sandbox. I bundled my test case a Mac .app, and signed it with the 
"com.apple.security.app-sandbox" entitlement.  When the signed app is 
run, my usual home directory is reported as !File.canRead(), and the 
user.home property returns a path under ~/Library/Containers/, which is 

I plan to label this as "noreg-hard" - signing an .app bundle requires 
Keychain setup for any machine running the test.

Webrev is here:

(One note - the change to
is not, strictly speaking, part of this fix, but was necessary for the 
"old build" to finish on my OS X 10.8.4 system.  I've left it in.)

An automated build+test run shows no (new) problems.



More information about the core-libs-dev mailing list