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

[Nicholas Rahn]

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. So in my export
dialog, the user would see the full Container path, even though the file
selection dialog had shown a normal ~/Documents path?

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? 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 ?

@Brent - you wrote:
"As it is now, apps needing to write app-specific data would need to
special-case for the App Sandbox and go find the Container directory, since
$HOME is not accessible (and only becomes accessible if the user interacts
with a FileDialog)."

Well, I already had to special case where I write app-specific data for
each of the 3 platforms I support (Mac, Windows & Linux). Any Java app that
is really cross-platform is going to have some platform specific code and
platform specific jvm-launching/packaging, if they want to do things the
recommended way for that platform. A sandboxed Mac version was just another
special case.  For that, I use the AppBundler fork to launch the JVM and
set some MAS specific properties so that I know that I'm running in the Mac
sandbox and where the Container directory is. Then the right
platform-specific initialization code in my app can be used to build the
app-specific data in the right place.

Thanks,
Nick

On Wed, Sep 11, 2013 at 2:27 AM, Brent Christian <brent.christian at oracle.com
> wrote:

> Adding a little to what Dave said, based on my understanding...
>
> On 9/10/13 3:36 PM, David DeHaven wrote:
>
> > Nicholas Rahn wrote:
>
>>
>>  In my app, the user selects where he wants to export individual
>>> files, such as CSVs and PDFs. These are files he'll use outside of
>>> my app.
>>>
>>> If user.home points to the app's sandbox Container, it will break
>>> this usage.  Opening a file dialog to
>>> /Users/Bob/Library/Containers/**my.app/Data/Documents will definitely
>>> confuse the user and if they save a file there, they will never be
>>> able to find it later from outside of my app.
>>>
>>
>> The user won't know the difference, all they'll see is ~/Documents as
>> provided by powerbox.
>>
>
> Note that PowerBox+NSOpenPanel recognize the Container path, and
> automagically take the user to their *actual* $HOME, Documents, etc
> directories.
>
> With this change, then, telling a native FileDialog to open user.home (or
> user.home/Documents, etc), will (still) show the user their real $HOME (or
> $HOME/Documents, etc) directory, whether sandboxed (user.home is the app
> Container, redirected by PowerBox to $HOME) or not (user.home=$HOME).
>
> The selected file returned from the FileDialog will point to a location
> within $HOME, and because of the *.files.user-selected.* entitlement, the
> app will now have access to it.
>
>
>  Yes, I understand the whole sandboxing concept. I'm not asking for
>>> unrestricted access to the file system. I use the
>>> "com.apple.security.files.**user-selected.read-write" entitlement so
>>> that the user can select where he wants to save files, and I want
>>> to present him with a standard, well-known, default location for
>>> that (like ~/Documents).
>>>
>>> If user.home doesn't point to the user's actual home folder (i.e.
>>> NSHomeDirectoryForUser), it makes creating a standard, well-known
>>> location path (like ~/Documents) much more difficult.
>>>
>>
> BTW, NSHomeDirectoryForUser() for the current user returns the same
> sandboxed value as NSHomeDirectory().
>
> Without this change, user.home is obtained using the POSIX getpwuid() call
> - really not the Apple-recommended way for dealing with the sandbox.
>
>
>  Powerbox solves exactly that problem... and yes, yes it is users home
>> folder, from the perspective of a sandboxed application!
>>
> >
> > ...
>
> >
>
>> the user will never see the app container path unless you
>> explicitly report it to them.
>>
>
> ...though it's really not mean to be presented to the user (and I haven't
> been able to convince FileDialog to take me to it).  The Container
> directory is meant only for files used by the app itself. From [1]:
>
> "The container is in a hidden location, and so users do not interact with
> it directly. Specifically, the container is not for user documents. It is
> for files that your app uses, along with databases, caches, and other
> app-specific data"
>
>
> The suggested change to the value of user.home means that it can be used
> by apps to write their own private data files AND (thanks to the PowerBox
> magic) point a user to their $HOME within a native file dialog, AND it will
> work inside or outside the App Sandbox.
>
> As it is now, apps needing to write app-specific data would need to
> special-case for the App Sandbox and go find the Container directory, since
> $HOME is not accessible (and only becomes accessible if the user interacts
> with a FileDialog).
>
> Thanks,
> -Brent
>
> [1] https://developer.apple.com/**library/mac/documentation/**
> security/conceptual/**AppSandboxDesignGuide/**AppSandboxInDepth/**
> AppSandboxInDepth.html#//**apple_ref/doc/uid/TP40011183-**CH3-SW15<https://developer.apple.com/library/mac/documentation/security/conceptual/AppSandboxDesignGuide/AppSandboxInDepth/AppSandboxInDepth.html#//apple_ref/doc/uid/TP40011183-CH3-SW15>
>