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

[Brent Christian]

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