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

Nicholas Rahn nick at transparentech.com
Fri Sep 6 10:24:21 UTC 2013

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


On Fri, Sep 6, 2013 at 11:27 AM, Alan Bateman <Alan.Bateman at oracle.com>wrote:

> On 05/09/2013 22:30, Brent Christian wrote:
>> :
>> I plan to label this as "noreg-hard" - signing an .app bundle requires
>> Keychain setup for any machine running the test.
>> Webrev is here:
>> http://cr.openjdk.java.net/~**bchristi/7199674/webrev.00/<http://cr.openjdk.java.net/~bchristi/7199674/webrev.00/>
>> (One note - the change to
>>   make/common/Defs-macosx.gmk
>> is not, strictly speaking, part of this fix, but was necessary for the
>> "old build" to finish on my OS X 10.8.4 system.  I've left it in.)
> I don't know Cocoa memory management but from a quick look at the
> NSAutoreleasePool docs then what you seems to be right. Folks on
> macosx-port-dev would be better to comment on that.
> I see that createUTF8CString doesn't handle malloc failing and it's not
> clear how CFStringGetCString behaves when called with NULL. In any case,
> this is all early startup and if we have malloc failing this early then we
> aren't going to get very far.
> One comment on the error case (fallback to "?") as this is now duplicated.
> It might be better to have this fallback in one place (GetJavaProperties)
> as I'm pretty sure we'll need to re-examine it at some point (we
> periodically hear about environments where user.name/user.home end up as
> "?", it's been mis-configured systems in all cases that I've looked at but
> arguably we should fail rather than use "?").
> The update to the old build is only interesting if this is back-ported to
> jdk7u. Hopefully Erik or someone in the build team will be allowed to set
> their phasers to kill soon.
> -Alan.

More information about the core-libs-dev mailing list