Re: java.security.AccessControlException: access denied (java.io.FilePermission derby.log read)

[olk <Ol...@web.de>]

Hi
I am getting the same

"java.security.AccessControlException: access denied (java.io.FilePermission
derby.log read)"

message, but in an other environment. 

I'm developing a applet to embed in a web page, contacting the derby local
database. I receive the error, when I try to open the database connection to
the local database. When I try the same piece of code within a Java
Application, I can contact the database with no error.

Yes, the applet is signed - so it should be allowed to read local files.

I'm wondering, if it might be related to the security manager.... ? When
creating the database, I did not assign a specific user and password as I'm
still in evaluating derby for a new project..? Unfortunately the
documentation isn't too detailed about NOT assigning a user and pass.

Thanks,
Oliver
-- 
View this message in context: http://www.nabble.com/java.security.AccessControlException%3A-access-denied-%28java.io.FilePermission-derby.log-read%29-tp13225812p14412606.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: java.security.AccessControlException: access denied (java.io.FilePermission derby.log read)

[olk <Ol...@web.de>]

Hi,

thanks for your reply.

I finally found the reason for that behavior .....well, that's what I think
.... :o)

After consulting countless forums and discussions I got some hints that this
is related to the java security manager. It looks like, there is a security
manager created, for each jar that is used by the applet. That means for
mycode.jar and for the derby.jar we have two security manager. Both are
working with different signatures, as I have not signed the derby.jar with
my signature. The stupid thing is, that the browser just asked to accept the
signature of mycode.jar.

One easy workaround is using a "System.setSecurityManager(null);" before
trying to open the connection. 

I found this not very clean - especially because I don't exactly know what
else this command does. I found some comments, that this might open the door
for other applets running in the same browser ( ... I did not try that yet
...so I cannot confirm.... maybe if I'll get some free time...)

Anyway the solution was easy after all - I just signed all the jars with the
same signature, which then let me open the connection without the
AccessControlException.

If someone finds a good documentation about this topic, ....pleeeease post
it here, I rather prefer to learn things by reading than by trial and
error...... :o)



-- 
View this message in context: http://www.nabble.com/java.security.AccessControlException%3A-access-denied-%28java.io.FilePermission-derby.log-read%29-tp13225812p14439550.html
Sent from the Apache Derby Users mailing list archive at Nabble.com.

Re: java.security.AccessControlException: access denied (java.io.FilePermission derby.log read)

[Kristian Waagan <Kr...@Sun.COM>]

olk wrote:
> Hi
> I am getting the same
> 
> "java.security.AccessControlException: access denied (java.io.FilePermission
> derby.log read)"
> 
> message, but in an other environment. 

Hello Oliver,

Are you connecting using the embedded driver?
(i.e. no hostname in your JDBC connection URL)
Can you post a stack trace for the exception, so we can see where it is 
originating from?


Sorry I can't give any more help at the moment, but getting more 
information might trigger others to answer as well.


thanks,
-- 
Kristian

> 
> I'm developing a applet to embed in a web page, contacting the derby local
> database. I receive the error, when I try to open the database connection to
> the local database. When I try the same piece of code within a Java
> Application, I can contact the database with no error.
> 
> Yes, the applet is signed - so it should be allowed to read local files.
> 
> I'm wondering, if it might be related to the security manager.... ? When
> creating the database, I did not assign a specific user and password as I'm
> still in evaluating derby for a new project..? Unfortunately the
> documentation isn't too detailed about NOT assigning a user and pass.
> 
> Thanks,
> Oliver