[icedtea-web] Bug: Unable to remove permissions on %USERPROFILE%.icedteasecuritytrusted.cacerts.tempon Windows

[Jiri Vanek]

On 04/09/2013 02:00 PM, Jacob Wisor wrote:
> "Jiri Vanek"<jvanek at redhat.com> wrote:
>> On 04/09/2013 02:01 AM, Jacob Wisor wrote:
>>> Hello there!
>>>
>>> I have come across a bug on Windows since the last patches on checks for absolutness of paths. Infact, I am not sure whether they are connected to this bug, hence I also do not want to make any asumption about the cause of it. Netx worked on Windows some recent patches before, and now it does not anymore. The application just exits with the attached stack trace and exceptions when no config exists in %USERPROFILE%.icedtea (that is running for the first time). The launching user has full permissions on all files and subfolders in his user profile folder. This bug persists when run as an administrator. It is definitly not a problem with incorrectly set permissions on trusted.cacerts.temp nor any inherited permissions.
>>> I do not know whether this is reproducable on Linux systems.
>>>
>>> @Jiri:
>>> Could you have a look into this (I would like to be able to test the pl localization with a running application as well)? Or, should I rather report it via Bugzilla and hope for the best?
>>>
>>> Regards,
>>> Jacob
>>>
>>
>> Hi again!
>> Hmhmh, I can (partially - similar but not same chain of exceptions) reproduce when I remove .icedtea
>> directory and  set my home to read only, But I doubt  that it is connected to recent patches.
>>
>> By studying the exception:
>>   - First -independent - exception is: Exception in thread "AWT-EventQueue-0"
>> net.sourceforge.jnlp.util.lockingfile.StorageIoException: java.io.IOException: Proces nie moze
>> uzyskac dostepu do pliku, poniewaz inny proces zablokowal jego czesc
>> (translated as "The process can not access the file because another process has locked a portion")
>>     * This happened immediately after start of itw-settings, and is moreover correct. No file to
>> read, nor possibility to create (no .icedtea dir) .. however start continues (this is the only
>> "added by new patch").
>> Then two more exceptions from old code arise:
>> java.lang.NullPointerException at
>> net.sourceforge.jnlp.security.viewer.CertificatePane.readKeyStore(CertificatePane.java:263)
>> and
>> java.io.IOException: Removing execute permissions on file
>> C:UsersJakob.icedteasecuritytrusted.cacerts.temp failed
>>          at net.sourceforge.jnlp.util.FileUtils.createRestrictedFile(FileUtils.java:181)
>>   * all three are unrelated in meaning each to each, but have same root - tehy can not create their
>> config files.
>>
>>
>> So the underlying issue is definitely hidden in disability to  create .icedtea directory.  As fixing
>> this can be pretty complicated, and may lead to bug in jdk itself do you think youcan live with
>> workarround to create %USERPROFILE%.icedtea manually?
>>
>> ANyway I will check once more when I got more free time.
>>
>> Thanx for checking,
>>     J.
> 
> Thank you for your timely response.
> The thing is, that the .icedtea folder gets created. Infact, all files get created, but it fails when trying to tamper with access rights on trusted.cacerts.temp. The following files and folders get created:
> 
> %USERPROFILE%\.icedtea
> %USERPROFILE%\.icedtea\security
> %USERPROFILE%\.icedtea\.appletTrustSettings
> %USERPROFILE%\.icedtea\security\trusted.cacerts.temp
> 
> On subsequent launches the app fails with an "Cannot create file %USERPROFILE%\.icedtea\security\trusted.cacerts.temp" error, though the file exists. I guess trusted.cacerts.temp should have been a temp file and be deleted when the JVM terminates. There is a temp file facility in J2SE that might help to deal with that (I have not looked into the code yet). So it seams that's probably the crux of the matter. But, indeed it could also be a bug in the J2SE runtime.
> 
> Unfortunatelly, I cannot work around it. The console portion of the app works fine, so I can review that. But, as you can see the major UI portion is out of reach for now. The localization is almost done and it is a little bit frustrating to not be able to review it with a running application. Lets hope this issue can be resolved before the next release date. ;)
> 

oook... I have attached patch which handles windows restricted files less strictly == tries to set
the permissions, but do not die if it can not. I have nowhere to test it right now so I hope it will
work.

I think you can elaborate with it now. But this issue will need more investigations on my side
//me have tu make some windows machine around...

Hope this helps,
J.


If this help, can you sent stderr? I think the issue will be only on X flag for _files_ but still no
machine where to verify (work in progress)
If the issue will be only X flag, then I will sent official patch.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: nonFatalPermissionManipulationForWindows.patch
Type: text/x-patch
Size: 2385 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130409/aebc8268/nonFatalPermissionManipulationForWindows.patch