Permissions flakiness

[Bill Michaelson]

Running in a Netscape 7.01 browser on a Linux box...

Applicable permissions lines in policy file...

permission java.io.FilePermission "${user.home}/mfn/default.wpt", "read,
write";
permission java.io.FilePermission "${user.home}/mfn/*", "read, write";

When first line is removed, access to file fails - like this:

java.security.AccessControlException: access denied
(java.io.FilePermission /home/bill/mfn/default.wpt read)
at
java.security.AccessControlContext.checkPermission(AccessControlContext.java:270)
at
java.security.AccessController.checkPermission(AccessController.java:401)
at java.lang.SecurityManager.checkPermission(SecurityManager.java:542)
at java.lang.SecurityManager.checkRead(SecurityManager.java:887)
at java.io.File.isDirectory(File.java:698)
at
sun.net.www.protocol.file.FileURLConnection.connect(FileURLConnection.java:65)
at
sun.net.www.protocol.file.FileURLConnection.getInputStream(FileURLConnection.java:156)
at java.net.URL.openStream(URL.java:960)
at WptMgr.loadWaypoints(WptMgr.java:17)
at GeoPlotPanel.<init>(GeoPlotPanel.java:167)
at GeoPlotPanel.<init>(GeoPlotPanel.java:76)
at GeoPlotBox.start(GeoPlotBox.java:21)
at sun.applet.AppletPanel.run(AppletPanel.java:370)
at java.lang.Thread.run(Thread.java:536)

...sooo...

If permission is granted when the file is explicitly listed, why not
with the wildcard spec? Wildcards (including the "-") work in other
circumstance for me. Am I missing something or is something broken?

Of possible relevance:

I have noticed a similarly puzzling failure when using isDirectory()
elsewhere which I worked around by using another mechanism.

[Dhek Bhun Kho]

Original message from Bill Michaelson <bi...@cosi.com> on Wed, 12 Mar 2003
07:22:00 -0500:

> If permission is granted when the file is explicitly listed, why not
> with the wildcard spec? Wildcards (including the "-") work in other
> circumstance for me. Am I missing something or is something broken?

Shouldn't you be leaving the '*' out of the line?

permission java.io.FilePermission "${user.home}/mfn/", "read, write";

--
Never ask the barber if you need a haircut.

[Bill Michaelson]

Um... I don't think so, but I tried this just now, per your suggestion,
and it does not work. But I would appreciate some more insight. Why
did you suggest this?

[Dhek Bhun Kho]

Original message from Bill Michaelson <bi...@cosi.com> on Thu, 13 Mar 2003
08:27:10 -0500:

Hey Bill,

> Dhek Bhun Kho wrote:
>> Original message from Bill Michaelson <bi...@cosi.com> on Wed, 12 Mar 2003
>> 07:22:00 -0500:

>> Shouldn't you be leaving the '*' out of the line?
>> permission java.io.FilePermission "${user.home}/mfn/", "read, write";
> Um... I don't think so, but I tried this just now, per your suggestion,
> and it does not work. But I would appreciate some more insight. Why
> did you suggest this?

No you're right, I was blabbering. The list I've got on policy files is
this:

target permission
------ ----------
filename just the file
directory/ the directory
directory/* the directory and all the files in the directory
* all files in the current directory
directory/- all files in directory and it's subfolders
<<ALL FILES>> ALL FILES!!! :D

Could it be because you used the '/' explictly instead of
'${/}'. That one get's reinterpreted by java, the first ('/') doesn't.
It's just a wild guess, but I think that mixing ${user.home} and the '/'
creates faulty file names internally. (mixing win32 naming and
unix ('/') naming)

Hope you solve this. Like to know whether it was due to the mixed up '/'
and '${/}'

--
It appears that after his death, Albert Einstein found himself
working as the doorkeeper at the Pearly Gates.

[Bill Michaelson]

I noted the mixing of portable and non-portable notation with regard to
the slash too. But the underlying system is UNIX, so that should not
have been relevant in my test cases.

However, since my last post, I (experimentally) learned that an
underlying assumption on my part was incorrect, and this probably
contributed to some confusion in observing results...

I learned that when the referenced file path is a symbolic link, that
the actual target must also be listed for permission explicitly (I had
assumed not). If it is not, the permission is denied, and worse, the
textual description of the failure in the exception thrown refers to the
link name only - not the actual target for which permission failed.

After modifying my file system structure and permissions in various ways
to accomodate this new knowledge, it is working reasonably. However, I
haven't accounted for everything to my satisfaction, and in the fog of
development, I've moved on to other matters. I'll post again if a
similar problem occurs.

Thanks for your attention.