Permission: java.util.PropertyPermission user.timezone write not granted to org.jnode.fs.ext2.Ext2Directory

Project:JNode Core
Component:Code
Category:bug report
Priority:minor
Assigned:Unassigned
Status:active
Description

As I have experimented with Jnode, I have run into a situation where every program I try to run from disk is killed by the SecurityManager, each for different reasons.

To figure out what is going on, I wrapped checkPermission() in a try-catch to report what was being denied.

OS: Jnode 0.2.6-dev (svn rev 3688 from trunk)
Exception: java.util.PropertyPermission user.timezone write not granted to org.jnode.fs.ext2.Ext2Directory

This might explain why I see Jan 1, 1970 as the date/time stamp on all of my files, including new ones I create on the disk.

How could I fix this?

Do I need to modify the Ext2Directory class somehow?

Or do I simply modify the org.jnode.security.permission and add a block to grant that permission?

Does the note about running a PrivilegedAction mean the class would have to be modified too?

How would something like this be fixed for general applications, not just plugins distributed with Jnode?

Write permission ?

Submitted by galatnm on Thu, 01/10/2008 - 15:25.

It's really strange that filesystem classes need to write a user property. I try to set permission to ext2 classes but no change, file dates are always 1970.01.14.

Fabien L.

#1

Submitted by Exile In Paradise on Thu, 01/10/2008 - 16:52.

The patch below avoids the Exception.
Closing this one because the patch resolved the exception... and why does the user.timezone need to be read? I don't know.
But as Fabien mentions, the date/timestamps are still off.
Should be a separately tracked bug.

--- org.jnode.fs.ext2.xml-dist 2008-01-10 09:20:01.000000000 -0600
+++ org.jnode.fs.ext2.xml 2008-01-10 09:26:49.000000000 -0600
@@ -24,4 +24,8 @@

+
+
+

#2

Submitted by Anonymous (not verified) on Thu, 01/24/2008 - 17:15.

#3

Submitted by Exile In Paradise on Thu, 01/24/2008 - 23:41.

In jnode/fs/descriptors/org.jnode.fs.ext2.xml, I was able to add an extension block for this permission, and stop the exception getting reported, but I cannot say whether that should be committed as a 'secure fix' or just a workaround.