RFR 7199674: (props) user.home property does not return an accessible location in sandboxed environment [macosx]
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 , and this
specific point comes from :
"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