I might be confused, so I'll write out my thoughts and people can
Since the path we need (read) access to is specified by the user in the
connection string, I thought these permissions should not be granted to
the Derby codebase, but rather for the application codebase using Derby.
This would mean the application would have to do a doPrivileged when
restoring/creating the database.  says: "... the call to doPrivileged
should be made in the code that wants to enable its privileges." After
the connection has been made, Derby's "core permissions" should be
sufficient to ensure normal operation again.
However, when running the network server, the approach mentioned above
will not work, and permissions to the backup locations would have to be
granted to derby.jar, not the application code. Then adding
doPrivileged-blocks to the derby.jar codebase is reasonable.
I think also I forgot that our policy file is just an example and for a
specific use (for instance running the tests). For a concrete
deployment, the user/administrator must add the proper permissions. The
fact that Derby was able to write the backup, but not read it, must be
attributed to more extensive usage of doPrivileged-blocks in one code
path over the other. I suppose the default policy file and the tests
must be written to be compatible with each other, and I think they will
be if we add more doPrivileged-blocks.
My initial concern was why other actions in the area are wrapped in
doPrivileged-blocks, while the backupRoot.exists() is not. Thought there
could be was a reason for that.
Does this make any sense?