You are viewing a plain text version of this content. The canonical link for it is here.
Posted to derby-dev@db.apache.org by Mike Matrigali <mi...@sbcglobal.net> on 2006/01/27 23:55:10 UTC
security manager implication of requiring one or multiple system
properties?
In the continuing discussion about how to fix DERBY-700, the
current most likely solution is to require one or more new
internally set system properties.
Basically there is a need to somehow in a single JVM to share
information from 2 classloaders, such that we can answer the
question of whether database X is currently opened by a
classloader in the current JVM. The proposal is to use the
java system property mechanism as the shared information point.
Is this ok use of system properties, with respect to the
on-going security work?
Re: security manager implication of requiring one or multiple system
properties?
Posted by Daniel John Debrunner <dj...@apache.org>.
Kathey Marsden wrote:
>
>>>From an existing user perspective:
>
> Our documentation says the following permission is mandatory:
> permission java.util.PropertyPermission "derby.*", read
> http://publib.boulder.ibm.com/infocenter/cscv/v10r1/topic/com.ibm.cloudscape.doc/cdevbabejgjd.html
I think that documentation is incorrect, reading derby.* properties is
not mandatory, even this sentence in that section implies it's optional:
"If the action is denied, properties in the JVM's system set are ignored."
I will check up on this though, just to be sure.
Dan.
Re: security manager implication of requiring one or multiple system
properties?
Posted by Kathey Marsden <km...@sbcglobal.net>.
Mike Matrigali wrote:
> In the continuing discussion about how to fix DERBY-700, the
> current most likely solution is to require one or more new
> internally set system properties.
>
> Basically there is a need to somehow in a single JVM to share
> information from 2 classloaders, such that we can answer the
> question of whether database X is currently opened by a
> classloader in the current JVM. The proposal is to use the
> java system property mechanism as the shared information point.
>
> Is this ok use of system properties, with respect to the
> on-going security work?
>
>
>From an existing user perspective:
Our documentation says the following permission is mandatory:
permission java.util.PropertyPermission "derby.*", read
http://publib.boulder.ibm.com/infocenter/cscv/v10r1/topic/com.ibm.cloudscape.doc/cdevbabejgjd.html
If we need to add "write" it would be good if existing policy files
still worked in the old capacity, preventing dual boot from separate
JVMS but not from dual classloaders and putting a warning in the log
that the permissions need to be changed to prevent dual boot of the
database.
Kathey
Re: security manager implication of requiring one or multiple system
properties?
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
FYI, I found this interesting blog.
http://www.jroller.com/page/oburn/20041005
I had discovered UID too, but it didn't seem to quite cover it. I am
wondering what he means by a "JVM property", but further searching makes
me think this is an IBM VM/Websphere-specific feature...
David
Daniel John Debrunner wrote:
> Daniel John Debrunner wrote:
>
>
>>Mike Matrigali wrote:
>>
>>
>>
>>>Note that the problem we are trying to solve is multiple derby
>>>instances from 2 classloaders accessing the same database at the
>>>same time. We are unlikely to ever allow this - as correct
>>>direct access to the database requires sharing a lot of information
>>>(page cache, lock tables, ...).
>>>
>>>I am not happy with the system property approach - but best I could
>>>come up with so far, and the thread describes the problems with current
>>>lock files.
>>>
>>>I don't know much about what is and is not available from different
>>>classloaders. I think all that is needed is some way to generate a
>>>unique key which can be used to identify what jvm instance I am in. The
>>>pid
>>>of the jvm would work, but I don't think it is available from java.
>>>Then each classloader in the jvm could use some sort of file lock to
>>>tell if another classloader in the same jvm existed.
>>
>>
>>I guess I'm not seeing the jump from unique jvm id to use of a file
>>lock. If a file lock doesn't prevent multiple threads within a JVM from
>>modifying a file, how does the unique jvm id help?
>
>
> Sorry, found the discussion of the possible algorithm at
>
> http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/%3c43D68A01.5050806@sbcglobal.net%3e
>
> Dan.
>
Re: security manager implication of requiring one or multiple system
properties?
Posted by Daniel John Debrunner <dj...@apache.org>.
Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>
>
>>Note that the problem we are trying to solve is multiple derby
>>instances from 2 classloaders accessing the same database at the
>>same time. We are unlikely to ever allow this - as correct
>>direct access to the database requires sharing a lot of information
>>(page cache, lock tables, ...).
>>
>>I am not happy with the system property approach - but best I could
>>come up with so far, and the thread describes the problems with current
>>lock files.
>>
>>I don't know much about what is and is not available from different
>>classloaders. I think all that is needed is some way to generate a
>>unique key which can be used to identify what jvm instance I am in. The
>>pid
>>of the jvm would work, but I don't think it is available from java.
>>Then each classloader in the jvm could use some sort of file lock to
>>tell if another classloader in the same jvm existed.
>
>
> I guess I'm not seeing the jump from unique jvm id to use of a file
> lock. If a file lock doesn't prevent multiple threads within a JVM from
> modifying a file, how does the unique jvm id help?
Sorry, found the discussion of the possible algorithm at
http://mail-archives.apache.org/mod_mbox/db-derby-dev/200601.mbox/%3c43D68A01.5050806@sbcglobal.net%3e
Dan.
Re: security manager implication of requiring one or multiple system
properties?
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
> Note that the problem we are trying to solve is multiple derby
> instances from 2 classloaders accessing the same database at the
> same time. We are unlikely to ever allow this - as correct
> direct access to the database requires sharing a lot of information
> (page cache, lock tables, ...).
>
> I am not happy with the system property approach - but best I could
> come up with so far, and the thread describes the problems with current
> lock files.
>
> I don't know much about what is and is not available from different
> classloaders. I think all that is needed is some way to generate a
> unique key which can be used to identify what jvm instance I am in. The
> pid
> of the jvm would work, but I don't think it is available from java.
> Then each classloader in the jvm could use some sort of file lock to
> tell if another classloader in the same jvm existed.
I guess I'm not seeing the jump from unique jvm id to use of a file
lock. If a file lock doesn't prevent multiple threads within a JVM from
modifying a file, how does the unique jvm id help?
Dan.
Re: security manager implication of requiring one or multiple system
properties?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
Note that the problem we are trying to solve is multiple derby
instances from 2 classloaders accessing the same database at the
same time. We are unlikely to ever allow this - as correct
direct access to the database requires sharing a lot of information
(page cache, lock tables, ...).
I am not happy with the system property approach - but best I could
come up with so far, and the thread describes the problems with current
lock files.
I don't know much about what is and is not available from different
classloaders. I think all that is needed is some way to generate a
unique key which can be used to identify what jvm instance I am in. The pid
of the jvm would work, but I don't think it is available from java.
Then each classloader in the jvm could use some sort of file lock to
tell if another classloader in the same jvm existed.
Alternate solutions are welcome.
David W. Van Couvering wrote:
> I have to agree with Dan -- I am a little uncomfortable using system
> properties to share VM-global information. *Ultimately* what I would
> like to see us solve is to actually allow multiple Derby instances to
> run under different classloaders, but putting that aside for a moment,
> couldn't we have a shared file or a system of lock files rather than
> depend on system properties?
>
> David
>
> Daniel John Debrunner wrote:
>
>> Mike Matrigali wrote:
>>
>>
>>> In the continuing discussion about how to fix DERBY-700, the
>>> current most likely solution is to require one or more new
>>> internally set system properties.
>>>
>>> Basically there is a need to somehow in a single JVM to share
>>> information from 2 classloaders, such that we can answer the
>>> question of whether database X is currently opened by a
>>> classloader in the current JVM. The proposal is to use the
>>> java system property mechanism as the shared information point.
>>
>>
>>
>> What information are you going to share that solves the problem? I guess
>> I must have deleted the e-mail about solving this issue with system
>> properties.
>>
>>
>>> Is this ok use of system properties, with respect to the
>>> on-going security work?
>>
>>
>>
>> I don't think the SecurityManager is going to be the problem, the bigger
>> problem is that other code can clear those properties or change the
>> complete system set.
>>
>> Dan.
>>
>>
Re: security manager implication of requiring one or multiple system
properties?
Posted by "David W. Van Couvering" <Da...@Sun.COM>.
I have to agree with Dan -- I am a little uncomfortable using system
properties to share VM-global information. *Ultimately* what I would
like to see us solve is to actually allow multiple Derby instances to
run under different classloaders, but putting that aside for a moment,
couldn't we have a shared file or a system of lock files rather than
depend on system properties?
David
Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>
>
>>In the continuing discussion about how to fix DERBY-700, the
>>current most likely solution is to require one or more new
>>internally set system properties.
>>
>>Basically there is a need to somehow in a single JVM to share
>>information from 2 classloaders, such that we can answer the
>>question of whether database X is currently opened by a
>>classloader in the current JVM. The proposal is to use the
>>java system property mechanism as the shared information point.
>
>
> What information are you going to share that solves the problem? I guess
> I must have deleted the e-mail about solving this issue with system
> properties.
>
>
>>Is this ok use of system properties, with respect to the
>>on-going security work?
>
>
> I don't think the SecurityManager is going to be the problem, the bigger
> problem is that other code can clear those properties or change the
> complete system set.
>
> Dan.
>
>
Re: security manager implication of requiring one or multiple system
properties?
Posted by Mike Matrigali <mi...@sbcglobal.net>.
a complete solution is not available yet, but the current thought
is that we need some way to uniquely identify the JVM that the
class loader is running in. One proposal is to have derby generate
such an ID, probably using some kind of UUID approach. Then put
the ID into the system property so that both classloaders can see
it. Suresh has pointed out there is probably some race condition
with this, if the 2 classloaders can't use any sort of java synchronization.
Once we have a unique ID, then we would use some standard kind of
file locking scheme from within both class loaders to see if a
class loader, from this JVM is working on the db I am opening.
The problem of preventing multiple JVM's works now and would
continue unchanged, we are exploring adding an extra step just
to catch the 2 classloaders from the same JVM's.
I would rather not use system properties, but haven't come up
with anything else yet.
If you have access to one of the mail archivers the interesting
exchanges are under the following subject:
Re: [jira] Commented: (DERBY-700) Derby does not prevent dual boot of
database from different classloaders on Linux
Daniel John Debrunner wrote:
> Mike Matrigali wrote:
>
>
>>In the continuing discussion about how to fix DERBY-700, the
>>current most likely solution is to require one or more new
>>internally set system properties.
>>
>>Basically there is a need to somehow in a single JVM to share
>>information from 2 classloaders, such that we can answer the
>>question of whether database X is currently opened by a
>>classloader in the current JVM. The proposal is to use the
>>java system property mechanism as the shared information point.
>
>
> What information are you going to share that solves the problem? I guess
> I must have deleted the e-mail about solving this issue with system
> properties.
>
>
>>Is this ok use of system properties, with respect to the
>>on-going security work?
>
>
> I don't think the SecurityManager is going to be the problem, the bigger
> problem is that other code can clear those properties or change the
> complete system set.
>
> Dan.
>
>
>
>
Re: security manager implication of requiring one or multiple system
properties?
Posted by Daniel John Debrunner <dj...@apache.org>.
Mike Matrigali wrote:
> In the continuing discussion about how to fix DERBY-700, the
> current most likely solution is to require one or more new
> internally set system properties.
>
> Basically there is a need to somehow in a single JVM to share
> information from 2 classloaders, such that we can answer the
> question of whether database X is currently opened by a
> classloader in the current JVM. The proposal is to use the
> java system property mechanism as the shared information point.
What information are you going to share that solves the problem? I guess
I must have deleted the e-mail about solving this issue with system
properties.
> Is this ok use of system properties, with respect to the
> on-going security work?
I don't think the SecurityManager is going to be the problem, the bigger
problem is that other code can clear those properties or change the
complete system set.
Dan.
Re: security manager implication of requiring one or multiple system properties?
Posted by Francois Orsini <fr...@gmail.com>.
Looking some of the security policy files in the trunk, I'd say that
you will probably need to add:
permission java.util.PropertyPermission
"derby.YourSharedInfoPropertyName", "read, write";
for the derby.jar codebase...assuming the access to the shared system
property will be done within the derby.jar codebase...
from a quick glance ;-)
--francois
On 1/27/06, Mike Matrigali <mi...@sbcglobal.net> wrote:
> In the continuing discussion about how to fix DERBY-700, the
> current most likely solution is to require one or more new
> internally set system properties.
>
> Basically there is a need to somehow in a single JVM to share
> information from 2 classloaders, such that we can answer the
> question of whether database X is currently opened by a
> classloader in the current JVM. The proposal is to use the
> java system property mechanism as the shared information point.
>
> Is this ok use of system properties, with respect to the
> on-going security work?
>
>
>