cannot launch jnlp on windows due to exception while creating native storage directory

[AlBundy33]

for details see karakun/OpenWebStart#570
if you use a manually created temp-dir (e.g. C:\temp\ows) this results in an exception during startup.

net.sourceforge.jnlp.LaunchException: Fatal: Initialization Error: Could not initialize application. The application has not been initialized, for more information execute javaws from the command line.
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:593)
	at net.sourceforge.jnlp.Launcher.launchApplication(Launcher.java:374)
	at net.sourceforge.jnlp.Launcher.access$300(Launcher.java:72)
	at net.sourceforge.jnlp.Launcher$TgThread.run(Launcher.java:661)
Caused by: java.lang.RuntimeException: Exception while creating native storage directory 'C:\temp\ows\netx-native-50323'
	at net.sourceforge.jnlp.cache.NativeLibraryStorage.createNativeStoreDirectory(NativeLibraryStorage.java:179)
	at net.sourceforge.jnlp.cache.NativeLibraryStorage.getNativeStoreDirectory(NativeLibraryStorage.java:157)
	at net.sourceforge.jnlp.cache.NativeLibraryStorage.addSearchJar(NativeLibraryStorage.java:135)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.doActivateJars(JNLPClassLoader.java:1294)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.lambda$activateJars$3(JNLPClassLoader.java:1179)
	at java.security.AccessController.doPrivileged(Native Method)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.activateJars(JNLPClassLoader.java:1180)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.initializeResources(JNLPClassLoader.java:830)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.<init>(JNLPClassLoader.java:352)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.createInstance(JNLPClassLoader.java:425)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:497)
	at net.sourceforge.jnlp.runtime.classloader.JNLPClassLoader.getInstance(JNLPClassLoader.java:470)
	at net.sourceforge.jnlp.Launcher.createApplication(Launcher.java:585)
	... 3 more
Caused by: java.io.IOException: Cannot rename C:\temp\ows\netx-native-50323.temp to C:\temp\ows\netx-native-50323
	at net.sourceforge.jnlp.util.RestrictedFileUtils.createRestrictedFile(RestrictedFileUtils.java:172)
	at net.sourceforge.jnlp.util.RestrictedFileUtils.createRestrictedDirectory(RestrictedFileUtils.java:62)
	at net.sourceforge.jnlp.cache.NativeLibraryStorage.createNativeStoreDirectory(NativeLibraryStorage.java:176)
	... 15 more

Are there maybe ACLs missing or is there something wrong with the filter?

IcedTea-Web/core/src/main/java/net/sourceforge/jnlp/util/RestrictedFileUtils.java

Line 96 in e8f02c4

if (OsUtil.isWindows()) {

IcedTea-Web/core/src/main/java/net/sourceforge/jnlp/util/RestrictedFileUtils.java

Line 51 in e8f02c4

private static final List<String> WIN_ROOT_PRINCIPALS = Arrays.asList("NT AUTHORITY\\SYSTEM", "BUILTIN\\Administrators");

I'm on a german windows and at least cacls shows other names.
-> locally I'm admin but had this issue also with regular user accounts.

cacls %TEMP%
C:\Users\AlBundy\AppData\Local\Temp NT-AUTORITÄT\SYSTEM:(OI)(CI)F
                                  VORDEFINIERT\Administratoren:(OI)(CI)F
                                  ALBUNDY-W10-VM\albundy:(OI)(CI)F
cacls c:\temp\ows
c:\temp\ows VORDEFINIERT\Administratoren:(OI)(CI)(ID)F
            NT-AUTORITÄT\SYSTEM:(OI)(CI)(ID)F
            VORDEFINIERT\Benutzer:(OI)(CI)(ID)R
            NT-AUTORITÄT\Authentifizierte Benutzer:(ID)C
            NT-AUTORITÄT\Authentifizierte Benutzer:(OI)(CI)(IO)(ID)C

[AlBundy33]

that is definitely an issue with WIN_ROOT_PRINCIPALS because the names a translated (on my system in german).
And because manually created folders do not contain my user as principal (instead an alias is used) the resulting ACLs are empty and therefore ITW has no access to the file.

Here are my notes:

String principalName = ae.principal().getName();
// NT AUTHORITY\\SYSTEM -> NT-AUTORITÄT\SYSTEM sidString: S-1-5-18
// BUILTIN\\Administrators -> VORDEFINIERT\Administratoren sidString: S-1-5-32-544
// https://learn.microsoft.com/en-us/windows/win32/secauthz/well-known-sids
// https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-security-identifiers
// https://github.com/diecknet/diecknet-scripts/blob/main/Snips/Get-LocalizedNTAuthority.ps1

// default-temp-dir
// before setting ACLs
cacls C:\Users\albundy\AppData\Local\Temp\netx-native-14897.temp
C:\Users\albundy\AppData\Local\Temp\netx-native-14897.temp NT-AUTORITÄT\SYSTEM:(OI)(CI)F
                                                         VORDEFINIERT\Administratoren:(OI)(CI)F
                                                         ALBUNDY-W10-VM\albundy:(OI)(CI)F
// after setting ACLs
cacls C:\Users\albundy\AppData\Local\Temp\netx-native-14897.temp
C:\Users\albundy\AppData\Local\Temp\netx-native-14897.temp ALBUNDY-W10-VM\albundy:(OI)(CI)F

// create new temp-dir

MD C:\temp\ows

SET TEMP=C:\temp\ows
SET TMP=C:\temp\ows

// start app with new temp-dir
"c:\Program Files\OpenWebStart\javaws.exe" "%USERPROFILE%\Downloads\jnlp.jnlp"

// before setting ACLs
cacls C:\temp\ows\netx-native-21388.temp
C:\temp\ows\netx-native-21388.temp VORDEFINIERT\Administratoren:(OI)(CI)(ID)F
                                   NT-AUTORITÄT\SYSTEM:(OI)(CI)(ID)F
                                   VORDEFINIERT\Benutzer:(OI)(CI)(ID)R
                                   NT-AUTORITÄT\Authentifizierte Benutzer:(ID)C
                                   NT-AUTORITÄT\Authentifizierte Benutzer:(OI)(CI)(IO)(ID)C
// This calls view.setAcl(list); with an empty list
// after setting ACLs
cacls C:\temp\ows\netx-native-21388.temp
C:\temp\ows\netx-native-21388.temp

[lso-du-sud-ouest]

Hello,
I'm also facing this issue with the French localisation of Windows where I can observe that the ACL associated to "NT AUTHORITY\SYSTEM" is removed because the identity used is then "AUTORITE NT\Système".

Comparing SID values should avoid such localization issues, but it seems there is no simple solution available with the Java SDK to get SID values instead of identity names (see https://stackoverflow.com/questions/7118290/how-to-convert-the-sid-to-string-and-vice-versa-in-java).

Moreover I can also see that on the Windows configuration deployed by my company, when IcedTea-Web creates a folder in %TEMP%, there is no explicit ACL set for the owner (i.e. my personal account). Instead there is an ACL set for "Authenticated Users" (SID S-1-5-11, see https://learn.microsoft.com/en-us/windows-server/identity/ad-ds/manage/understand-special-identities-groups#authenticated-users). And unfortunately, when IcedTea-Web filters the ACLs, it removes the one set for "Authenticated Users" (SID S-1-5-11) because it is not white-listed in the variable WIN_ROOT_PRINCIPALS and because "Authenticated Users" is not the owner of the created folder.

Fixing the localization issue and white-listing "Authenticated Users" (SID S-1-5-11) would help a lot.

Thanks.

[lso-du-sud-ouest]

Hello,
Instead of white-listing "Authenticated Users" (SID S-1-5-11) in WIN_ROOT_PRINCIPALS, you could just add an explicit ACL for the file/directory owner as it is done in the code for non-Windows platforms.

It will not fix the principle name issue for systems/user sessions configured not to use English, but at least it will ensure that the owner doesn't lose his permissions.

Thanks.

[janakmulani]

@AlBundy33 thanks for reporting this. I would like you to test a fix before I release it. Please send me a mail at [email protected]