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

[Mike Duigou]

The non-MacOS parts look fine to me. I can't comment on the Objective C or MacOS code but the test you describe seems sufficient to confirm it is correct.

I am surprised that strdup isn't needed for the constant "?" string but java_props_md.c seems to include other constant strings in sprops so I will assume it is just never deallocated in the lifetime of the JVM.

Mike

On Sep 5 2013, at 14:30 , Brent Christian wrote:

> Please review my changes for 7199674
> (http://bugs.sun.com/view_bug.do?bug_id=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 readable.
> 
> I plan to label this as "noreg-hard" - signing an .app bundle requires Keychain setup for any machine running the test.
> 
> Webrev is here:
> http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/
> 
> (One note - the change to
>  make/common/Defs-macosx.gmk
> 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.
> 
> Thanks,
> -Brent
> 
> [1] http://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/AboutAppSandbox/AboutAppSandbox.html
> [2] https://developer.apple.com/library/mac/documentation/Security/Conceptual/AppSandboxDesignGuide/DesigningYourSandbox/DesigningYourSandbox.html