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

Brent Christian brent.christian at oracle.com
Wed Sep 11 22:07:17 UTC 2013


On 9/11/13 11:09 AM, Nicholas Rahn wrote:
> On David DeHaven wrote:
 >
>> In my app, I have an export dialog where the user can select the
>> file to export as well as choose some other export options. In
>> that dialog, after the user has selected the file to export (via
>> the file selection dialog), I display the full path to the file
>> that was returned from the file selection Dialog.
>>
>> So, if I understand you correctly (sorry, I haven't had time to
>> verify this myself), with this change, passing in
>> "user.home/Documents" to the file dialog, the user will see
>> "~/Documents" in the file dialog, but the full Container path will
>> be returned as the selected file.

The user will see ~/Documents, and a selected file in ~/Documents will 
have a full path into ~/Documents.

The user is not meant to know anything about the sandbox container, and 
the file dialog enforces that.  If you point it to the Container path, 
it takes you to ~ instead, and from then on you're working within ~.

>> The bottom line is, if what you have now allows you to write to
>> ~/Documents and you're sandboxed then this change should not
>> affect your application at all, except maybe in the UI if you're
>> displaying that path to the user. The user won't notice the
>> difference otherwise.
>
> My users *will* notice because I display this path in the export dialog,
> along with the other export options they can use.

If the path displayed is coming from the selected file, then it will 
continue to show the correct path.

> Side note: I'm using SWT and it boils down to the NSOpenPanel and
> NSSavePanel.

Yep, that should work fine.

> Additionally what's not clear is (again, sorry, I haven't had time to
> verify this myself), if I do export the file to the Documents
> directory under the Container path, where does the file actually get
> saved? In /Users/nick/Documents or in
> /Users/nick/Library/Container/my.app/Data/Documents?

A path selected by the user using a file dialog will not point into the 
Container; you'd have to go out of your way to do this.

But if you did, say, write a file into
   /Users/nick/Library/Container/my.app/Data/Documents/
that's where it would get written.

> If it saves it to the Container's Documents folder, for other
> applications (Finder, Excel, Preview, etc) will it be visible in
> /Users/nick/Documents ?

No - as you point out, there's no symlink for Documents - they're 
different directories.

> The Documents directory in the Container is NOT a symlink. It
> is an actual directory.  So the 2 key questions are:
>
> 1. Is there a way to convert from
> /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv to
> ~/Documents/somefile.csv to display in the UI for the user?

I haven't heard of anything special to help do that.  I don't imagine 
that's something that is expected to be needed.

> 2. If the file gets saved to
> /Users/nick/Library/Containers/my.app/Data/Documents/somefile.csv, can
> other applications (such as Excel) access the file from
> ~/Documents/somefile.csv ?

No, the container directory is hidden.  It would not be visible to the 
Finder or most other apps without some extra work on the part of the user.

Again, this is why files meant for user consumption shouldn't go into 
the container.

> What bothers me about this proposed change is that you're taking away
> a useful property (the user's $HOME) and replacing it with something
> that, to me, is best done in an app's platform specific code, not in
> the JDK's. And I still need to know the user's $HOME, since the
> answers to my 2 questions above are probably 'no', so I'll have to
> add more to my app's Mac sandbox-specific code to get it.

$HOME is not accessible to a sandboxed app, except through a file 
dialog, and the file dialog will still take you $HOME with the updated 
value of user.home.

Given how it all works, the usefulness of $HOME within the sandbox seems 
pretty low (reflected by the fact that Apple returns the Container path 
instead of $HOME when NSHomeDirectory is called within the sandbox).

Our aim here, of course, is to require *less* platform-specific code to 
do the right thing, in particular to minimize extra code needed to move 
an app to the App Sandbox by following Apple's recommendations re: 
NSHomeDirectory vs getpwuid().

Thanks,
-Brent



More information about the core-libs-dev mailing list