harmony-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Stepan Mishura" <stepan.mish...@gmail.com>
Subject Re: [classlib][logging] A non bug difference from RI?
Date Wed, 30 Aug 2006 06:56:53 GMT
On 8/30/06, Andrew Zhang wrote:
>
> Hi folks,
>
> When SecurityManager is enabled and all file permissions are disabled, RI
> fails to new a FileHandler while Harmony allows.
> Following test code shows the differences:
>
>    public void test_FileHandler() throws Exception {
>        FileHandler handler = new FileHandler();
>        SecurityManager originalSecurityManager = System.getSecurityManager
> ();
>        try {
>            System.setSecurityManager(new MockFileSecurityManager());
>            handler.publish(new LogRecord(Level.SEVERE, "msg"));
>
> // SecurityException is thrown here
>            handler.close();
>        } finally {
>            System.setSecurityManager(originalSecurityManager);
>        }
>    }
>
>    public static class MockFileSecurityManager extends SecurityManager {
>        public void checkPermission(Permission perm) {
>            if (perm instanceof FilePermission) {
>                System.out.println("check " + perm.getName());
>                throw new SecurityException();
>            }
>        }
>    }
> FileHandler.close() spec says "Throws: SecurityException - if a security
> manager exists and if the caller does not have
> LoggingPermission("control").", In the code above, control permission is
> allowed. The failure stack trace against RI looks like:
>
> java.lang.SecurityException
> at com.andrew.LoggingTest$MockFileSecurityManager.checkPermission(
> LoggingTest.java:131)
> at java.lang.SecurityManager.checkRead(SecurityManager.java:871)
> at java.io.File.exists(File.java:700)
> at java.io.Win32FileSystem.canonicalize(Win32FileSystem.java:401)
> at java.io.File.getCanonicalPath(File.java:531)
> at java.io.FilePermission$1.run(FilePermission.java:218)
> at java.security.AccessController.doPrivileged(Native Method)
> at java.io.FilePermission.init(FilePermission.java:212)
> at java.io.FilePermission.<init>(FilePermission.java:264)
> at java.lang.SecurityManager.checkDelete(SecurityManager.java:990)
> at java.io.File.delete(File.java:869)
> at java.util.logging.FileHandler.close(FileHandler.java:594)
> at com.andrew.LoggingTest.test_FileHandler(LoggingTest.java:121)
> ...
>
> The output is "check C:\Documents and Settings\myaccount\java0.log.lck"
>
> It seems RI tries to delete <log file>.lck file, but has no permission.
> ".lck" file is never mentioned in spec, and should be implementation
> detail.
>
> Current Harmony code never tries to lock a temp empty .lck file, so the
> test
> passes against Harmony.


If I understoond correctly, new FileHandler() creates temporary file for
logging (its name is defined by default configuration properties). That is
true for Harmony and RI. Right?

RI tries to delete the created file if FileHandler.close() is invoked. And
Harmony doesn't. Why?

Thanks,
Stepan.

If we revise the MockSecurityManager a little, to allow .lck file
> permission,
>
>    public void checkPermission(Permission perm) {
>            if (perm instanceof FilePermission) {
>                if (perm.getName().indexOf(".lck") == -1) {
>                    System.out.println("check " + perm.getName());
>                    throw new SecurityException();
>                }
>            }
>        }
>
> The test will pass both against RI and Harmony.
>
> So I'd suggest to leave it as "non-bug difference from RI".
>
> Any comments? Thank you!
>
>
>
> --
> Andrew Zhang
> China Software Development Lab, IBM
>
>


-- 
Thanks,
Stepan Mishura
Intel Middleware Products Division

------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: harmony-dev-unsubscribe@incubator.apache.org
For additional commands, e-mail: harmony-dev-help@incubator.apache.org

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message