[icedtea-web] Bug: Unable to remove permissions on %USERPROFILE%\.icedtea\security\trusted.cacerts.temp on Windows

Jiri Vanek jvanek at redhat.com
Wed Apr 10 05:48:18 PDT 2013

Thank you for deep investigations.
>From this log is clear that the fatal exception is from newest commmits ad thank you very much for

I Will try to fix the handling of LockedFile and its exception (acually added by me and Adam few
weeks ago :( )  asap (but I'm unfortunately quite bussy right now :-/)

I'm quite agreeing with you on restricted file usefulness. But its removal/refactoreing will have to
wait for 1.5. But for 1.4 this windows issue must be fixed(damn).

Sorry for delaying you form better stuff, but give me few days!

Best regards

ps /me keeping you in mind!

-------- Original Message --------
Subject: Re: [icedtea-web] Bug: Unable to remove permissions on
%USERPROFILE%\.icedtea\security\trusted.cacerts.temp on Windows
Date: Wed, 10 Apr 2013 21:00:41 +0900
From: Jacob Wisor <gitne at excite.co.jp>
To: JiriVanek <jvanek at redhat.com>, ""@excite.co.jp

"Jiri Vanek"<jvanek at redhat.com> wrote:
> On 04/09/2013 05:33 PM, Jacob Wisor wrote:
> > "Jiri Vanek"<jvanek at redhat.com> wrote:
> >> 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%.icedteasecuritytrusted.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.
> > 
> > Thank you for this prompt attempt.
> > Unfortunatelly, it does not help :( or maybe sort of, but the GUI still does not pop up. I have attached the stderr log. The resulting files that I get now are:
> > 
> > %USERPROFILE%\.icedtea
> > %USERPROFILE%\.icedtea\security
> > %USERPROFILE%\.icedtea\.appletTrustSettings
> > %USERPROFILE%\.icedtea\security\trusted.cacerts
> > 
> > It seems to me like the file permissions facility in J2SE is broken on Windows systems, since the access rights system on Windows which is based on ACLs works entirely different than on U*ix systems. Besides, it has been introduced only since Java 6. I will have a closer look into this issue later this evening, and I am going to try to build netx on my Fedora VM. Updating to the latest JRE on Windows may help, although I am sceptical. Maybe there is some hope afterall. ;)
> > 
> > Thanks again for bothering :)
> > Jacob
> > 
> The attachment is missing :((
> /me curious

Hello Jiri,

Sorry, the web mailer is lausy. :( So, here we go again.

I have played a little bit with J2SE's access permissions facility on Windows, that is
java.io.File.setExecutable(boolean,boolean), java.io.File.setWriteable(boolean,boolean), and
java.io.File.setReadable(boolean,boolean). They obviously have no effect on Windows, so one cannot
rely on them. Besides, as far as I can tell the whole purpose of this fiddling with access
permissions on files is to get a locked file. IMHO the
net.sourceforge.jnlp.util.FileUtils.createRestrictedFile(File,boolean,boolean) is redundant and
totally misses the point. Actually, there is a file locking facility provided by J2SE via
java.nio.channels.FileLock. Although the semantics of java.nio.channels.FileLock can characterized
as best effort on varying platforms at best it probably should be used nevertheless. Infact, there
is even a utility class net.sourceforge.jnlp.util.lockingfile.LockedFile in netx. So, I am a little
bit confused. Why not use that? Correct me if I am wrong, but even if java.nio.c!
 hannels.FileLock does not provide the desired semantics - let's say perhaps on Linux - fiddling
with file access permissions should not be the way to go. Instead, then the prefered way would be to
use buffers from java.nio (to get some sort of memory-mapped file) or java.io.BufferdIn/OutputStream
with java.io.PipedIn/OutputStream. This process of creating netx' data files should probably be
revised and refactored.
To cut a long story short, it still does not run on Windows. :D And, I probably will not have the
time to refactor it. So it is nice of you to help me out.


-------------- next part --------------
A non-text attachment was scrubbed...
Name: netx.stderr.log
Type: application/octet-stream
Size: 3536 bytes
Desc: not available
Url : http://mail.openjdk.java.net/pipermail/distro-pkg-dev/attachments/20130410/c19855e6/netx.stderr.log 

More information about the distro-pkg-dev mailing list