On 8/30/06, Andrew Zhang wrote:
On 8/30/06, Stepan Mishura wrote:
>
> 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?
Stepan, you missed something here. :)
Both Harmony and RI creates a file (not temporary) for logging, and RI
created one more file(temporary) for locking.
RI tries to delete the temporary .lck file when fileHandler.close() is
invoked. Harmony has nothing to be deleted. :)
IOW, Harmony uses different locking approach for log-files and the test
above demonstrate side-effect of different approaches. Right?
IMO, we should add a note to the documentation: why we chose different
locking approach.
Thanks,
Stepan.
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
> >
------------------------------------------------------
Terms of use : http://incubator.apache.org/harmony/mailing.html
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
