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

[Brent Christian]

Hi, Nick.  Thanks for your feedback.  I'm glad to hear from someone who 
has experience with App Store deployment.

On 9/6/13 2:17 PM, Nicholas Rahn wrote:
> If you're saying that NSHomeDirectory is the correct behaviour for the Java
> user.home property, then I have to disagree. On every other platform,
> including non-sandboxed Mac, user.home is the actual user's home directory
> (i.e. /home/<user> or /Users/<user> or C:\Users\<user>).

NSHomeDirectory still returns /Users/<user> on non-sandboxed Mac.

 From my testing today, it seems the native Mac file dialog (which 
underlies java.awt.FileDialog) does understand the "sandboxed" 
NSHomeDirectory path.  If you FileDialog.setDirectory() to it, the 
dialog comes up showing /Users/<user>.  This also works directories 
contained in ~, such as ~/Documents.

(All this requires 
com.apple.security.files.user-selected.[read-only|read-write], of course).

So that's a bit surprising, though it does mean that:

   String userHomePath = System.getProperty("user.home");
   myFileDialog.setDirectory(userHomePath + "/Documents");

will give you a FileDialog pointing to ~/Documents whether or not you're 
running in the sandbox.


My understanding is that, when sandboxed, the *only* way to access files 
within the User's "real" home directory is by selecting them in the 
native file browser.  And of course at that point, you can get the path 
from the selected file.

The difference, then, is how user.home can be used outside the context 
of a FileDialog.  Currently, I think the answer when running in the 
sandbox is "it can't" (unless there are other Entitlements that would 
make the path to ~ accessible).

So the thinking here is that there is more value in having user.home 
reflect an accessible location.

> Setting user.home
> to the *application's* home directory (which is what NSHomeDirectory
> returns in a sandboxed environment) would seem to me to break the
> definition of the user.home property.
 >
> On a mac, in a sandboxed and non-sandboxed environment, I would expect
> user.home to be NSHomeDirectoryForUser.>

I can look into NSHomeDirectoryForUser.  NSHomeDirectory was used 
because it's what is mentioned in the Apple documentation I've seen 
regarding the App Sandbox.

> A sandboxed Java app definitely
> needs to know about the app's Container directory (and even whether it's
> actually being run sandboxed or not), but redefining user.home doesn't seem
> like the right solution. Having AppBundler (or even the JRE) provide that
> information via special properties feels better from my developer's
> perspective.

Adding an additional special property may or may not fly, but I can look 
into it.

Thanks,
-Brent

> On Fri, Sep 6, 2013 at 6:18 PM, David DeHaven <david.dehaven at oracle.com>wrote:
>
>>
>>>> As someone with a Java app in the Mac App Store (MAS), I would like to
>> vote against this change.
>>>>
>>>> It is still important to know the user's actual home directory
>> (/Users/<username>) even if the app is running in the sandbox.  Using the
>> entitlement, com.apple.security.files.user-selected.read-write, we can
>> still write to user selected directories (such as ~/Documents).  So
>> changing the user.home property to point to somewhere in the app's
>> Container would make it more difficult to get the actual home directory and
>> thus, other directories that the end-user is familiar with. I also think
>> this change would lead to more developer confusion and make application
>> code more complicated.
>>>>
>>>> I don't know all what the user.home property is used for in the JDK
>> itself, but concerns about the MAS sandbox would be, IMHO, better handled
>> using special Mac/MAS only properties, such as those setup by
>> infinitekind's Appbundler fork on bitbucket:
>> https://bitbucket.org/infinitekind/appbundler
>>>>
>>>> Nick
>>> I'm sure Brent wants to do the right thing here and maybe this needs
>> some input from the Apple or other Mac-savvy folks as to whether sandboxed
>> apps are really supposed to know about the actual user's home directory.
>>>
>>> FWIW, the original recommendaiton to switch to NSHomeDirectory came from
>> Scott Kovatch when he was working on Application Bundler. It's very
>> possible that things have changed since then.
>>
>>
>> I haven't had a chance to look at the changes yet, so this may be a bit
>> premature...
>>
>>
>> Using NSHomeDirectory is the CORRECT behavior, whether the app is
>> sandboxed or not (that extends to ALL apps, not just Java based).
>>
>> If the application needs to access Documents, Music, Movies, etc then
>> those entitlements need to be added. Additionally, even if sandboxed an
>> application can open documents in any folder the user has access to as long
>> as the standard file chooser is used (which I believe we already do), the
>> app will be granted (indirect) access to the selected file(s).
>>
>> -DrD-
>>
>>