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

Jacob Wisor gitne at excite.co.jp
Thu Apr 25 11:15:18 PDT 2013


"Jiri Vanek"<jvanek at redhat.com> wrote:
> 
> 
> 
> -------- Original Message --------
> Subject: Re: [icedtea-web] Bug: Unable to remove permissions on
> %USERPROFILE%.icedteasecuritytrusted.cacerts.temp on Windows
> Date: Fri, 19 Apr 2013 17:57:49 +0200
> From: Jiri Vanek <jvanek at redhat.com>
> To: Jacob Wisor <gitne at excite.co.jp>,        IcedTea Distro List <distro-pkg-dev at openjdk.java.net>
> 
> On 04/10/2013 02:48 PM, Jiri Vanek wrote:
> > Thank you for deep investigations.
> >> From this log is clear that the fatal exception is from newest commmits ad thank you very much for
> > reporting.
> > 
> > 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
> >     J.
> > 
> > ps /me keeping you in mind!
> > 
> > 
> > 
> > -------- Original Message --------
> > Subject: Re: [icedtea-web] Bug: Unable to remove permissions on
> > %USERPROFILE%.icedteasecuritytrusted.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%.icedteasecurity
> >>>>> %USERPROFILE%.icedtea.appletTrustSettings
> >>>>> %USERPROFILE%.icedteasecuritytrusted.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%.icedteasecurity
> >>> %USERPROFILE%.icedtea.appletTrustSettings
> >>> %USERPROFILE%.icedteasecuritytrusted.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.
> > 
> > Regards,
> > Jacob
> > 
> > 
> Ok. I have reproduced this on windows, and the attached "fix" is
> working.
Okay cool! :) Thank you. So, I did not talk rubbish and was not doing anything wrong after all. :D

> I myself consider locking file as little bit overpowered stuff,
> designed fot case that one applet will write record, whether other
> applet will in meantime read record, so I do not think there will
> be any harm by disabling on windows (as applets are not known to
> run on win(?))

Well, locking a file via a system's file locking mechanism is an acceptable way to achieve exclusion. But, maybe a global (JVM-wide) object lock would do as well, as long as all applets share the same JVM. I have not used objects (besides serialization) or locks across application domains in Java, and I do not know whether that is possible in Java after all, but probably is. It is definitely possible on the .net platform.
 
> ps - how looks PL? O:)

In the meantime, I have transfered the localized message properties to a Fedora VM and it works fine. But, there was not enough time to polish and streamline the PL messages. See my rfc please.

Jacob



More information about the distro-pkg-dev mailing list