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

[David DeHaven]

This isn't every other platform, this is Mac OS X and all the baggage that goes along with it! :)

What do you actually need access to user.home for? Do you have empirical evidence that this will break your application?

The whole point of sandboxing is you no longer have direct access to the entire system. The app must play inside it's sandbox, period, end of story. Gone are the days of unrestricted access to the filesystem, that's the whole point of sandboxing! This is all pretty well outlined in the "Sandboxing Your App" documentation on ADC.

Powerbox is there to solve your problem of opening user documents (with the right entitlements) and there are mechanisms in place to allow opening related files (with the users permission of course). Even a sandboxed application can show the user the contents of his various folders in a file open dialog. This all happens regardless of whether NSHomeDirectory returns /Users/JoeBob or /Users/JoeBob/Library/Containers/com.blah.someapp

-DrD-

> 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>). 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. 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.
> 
> Nick
> 
> 
> 
> 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-
> 
>