Derby secure by default
The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
Rick, I’d vote for secure by default in v.11. Thanks On Mon, Sep 19, 2011 at 6:39 PM, Rick Hillegas rick.hille...@oracle.com wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
RE: Derby secure by default
Off by default for the release coming out. On by default if you want at the next major release. -Original Message- From: Rick Hillegas [mailto:rick.hille...@oracle.com] Sent: Monday, September 19, 2011 12:39 PM To: Derby Discussion Subject: Derby secure by default The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
derby can not reload procedure class? can not use ResultSet.updateRow()?
nice to contact every one,This is my first time to mail in english,please
forgive me.
#1.It seems that when procedure in a class was loaded, drop and reloaded, the
changes of JAR file havn't take effected!
eg script:
drop PROCEDURE test;
call sqlj.remove_jar('admin.creaateClient', 0);
call sqlj.install_jar('export\testproc.jar','admin.creaateClient', 0);
CREATE PROCEDURE test( IN orgID INTEGER,
IN groupID INTEGER,
IN name varchar(60),
IN faceFileID bigint,
IN recStatus smallint,
IN creator bigint
)
PARAMETER STYLE JAVA READS SQL DATA LANGUAGE JAVA
EXTERNAL NAME 'com.bana.commonServer.procedure.Client_info.creaateClient';
call test(1,2,'name',4,5,6);
-- code ended
when I change and re-complie the JAR ( a little changes of logic,nothing of
the other changeed), I repeat the script but the logic is the old one...囧
#2
sql = SELECT groupSize,seq from SEQ where seqType =101 and orgID =? and
groupID =? ;
pSeq= connection.prepareStatement(sql,
ResultSet.TYPE_FORWARD_ONLY,ResultSet.CONCUR_UPDATABLE);
pSeq.setInt(1, orgID);
pSeq.setInt(2, groupID);
System.out.println( exe SQL：+sql);
rs = pSeq.executeQuery();
if(rs.next()){
groupSize =rs.getInt(1);
seq = rs.getInt(2);
System.out.println(seq:+seq);
if(seq=groupSize){
//returnCode[0] =4002;
return;
}
System.out.println(groupSize:+groupSize);
rs.updateInt(seq, seq+1); /not executed
rs.updateRow();//not executed
System.out.println(update:+seq+1);//not executed
the return message is:
The exception 'java.sql.SQLException: ' was thrown while evaluating an
expression.
I try the same code in independent java source and execute passed.I feel
confused ,It my first time to try derby
I look forward to your reply.thank you for you intention.
Re: Derby secure by default
I am not sure how it applies to all of these points, but I am wondering if secure by default should be implemented on a per database basis rather than a system level basis? It seems wierd that security could change based on how the next embedded startup set a flag. What about having the property be part of what user requests at database creation time? And maybe allow some secure way either disable or enable it. The discussion could continue on what the default for a newly created database would be. At least for point 1-4 seems to make more sense, not sure about 5,6. I personally think many of these points make most sense for derby network server. While many possibly get in the way for many zero-admin embedded applications. Since we have one codeline for the most part for both it is hard to have one default. Rick Hillegas wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
Installing a new version should always be backward compatible and not break anything in existing applications. If things don't work this way, it's bound to be (unncessarily) disruptive to some, and especial ly those less sophisticated and less able to figure out and fix problems. I see no reason why anyon e who wishes to utilize the new capabil ities would have any problem with setting the new property when they are ready to do so. Security is obviously important, especially for networked applications. I think it's also important not to do anything that interferes with embedded applications designed to require ZERO administration. - Original Message - From: Rick Hillegas rick.hille...@oracle.com To: Derby Discussion derby-user@db.apache.org Sent: Monday, September 19, 2011 12:39:07 PM Subject: Derby secure by default The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
Hi Mike, Some comments inline... On 9/19/11 10:38 AM, Mike Matrigali wrote: I am not sure how it applies to all of these points, but I am wondering if secure by default should be implemented on a per database basis rather than a system level basis? It seems wierd that security could change based on how the next embedded startup set a flag. I think that it should behave like derby.database.sqlAuthorization: once it's been turned on it is stored in the database and you can't turn it off at the system level. I agree that it would be weird to let the next user subvert the security of your database by flipping a command line switch. What about having the property be part of what user requests at database creation time? And maybe allow some secure way either disable or enable it. The discussion could continue on what the default for a newly created database would be. At least for point 1-4 seems to make more sense, not sure about 5,6. I personally think many of these points make most sense for derby network server. I'm also concerned about the embedded database on a USB stick. I could argue that it is more vulnerable than the server-side database locked up in a machine room. While many possibly get in the way for many zero-admin embedded applications. I'm imagining that this change may be fairly unobtrusive. For an embedded database which has only one user (the dbo), the big change is that the dbo has to specify a username and password. There won't be any need to GRANT access to other users so (2) won't be noticed. Items (3) and (4) won't burden most applications. (5) and (6) are only issues for client/server usage. Since we have one codeline for the most part for both it is hard to have one default. I agree that a common default would be best. It will make it easier to reason about Derby's behavior and simplify our user guides. Thanks, -Rick Rick Hillegas wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
(perhaps this has already been discussed in the devs' mailing list, if so, forgive my ignorance). I'm not sure whether making the default value on will actually improve security as a whole. If a developer hasn't given thought to security, there are plenty of other pitfalls that may compromise an application (e.g. where should I store the (previously unneeded yet now required) username and password?). On the other hand, if s/he did in fact think about security, then odds are that are a simple, concise documentation will point him/her to happily turn on the switch with minimum nuisance, and proceed to secure the rest of the application. @Roy: I believe that, since the change would happen in a next major release (11 vs. current 10.x), backwards compatibility wouldn't be *required* (but would certainly be *appreciated*). On Mon, Sep 19, 2011 at 4:55 PM, Rick Hillegas rick.hille...@oracle.comwrote: Hi Mike, Some comments inline... On 9/19/11 10:38 AM, Mike Matrigali wrote: I am not sure how it applies to all of these points, but I am wondering if secure by default should be implemented on a per database basis rather than a system level basis? It seems wierd that security could change based on how the next embedded startup set a flag. I think that it should behave like derby.database.**sqlAuthorization: once it's been turned on it is stored in the database and you can't turn it off at the system level. I agree that it would be weird to let the next user subvert the security of your database by flipping a command line switch. What about having the property be part of what user requests at database creation time? And maybe allow some secure way either disable or enable it. The discussion could continue on what the default for a newly created database would be. At least for point 1-4 seems to make more sense, not sure about 5,6. I personally think many of these points make most sense for derby network server. I'm also concerned about the embedded database on a USB stick. I could argue that it is more vulnerable than the server-side database locked up in a machine room. While many possibly get in the way for many zero-admin embedded applications. I'm imagining that this change may be fairly unobtrusive. For an embedded database which has only one user (the dbo), the big change is that the dbo has to specify a username and password. There won't be any need to GRANT access to other users so (2) won't be noticed. Items (3) and (4) won't burden most applications. (5) and (6) are only issues for client/server usage. Since we have one codeline for the most part for both it is hard to have one default. I agree that a common default would be best. It will make it easier to reason about Derby's behavior and simplify our user guides. Thanks, -Rick Rick Hillegas wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
Embedded applications have to secure their own points of entry and turning Derby security on by default will do nothing. Unless the Java security manager is active, everything is wide open via the reflection APIs when you are embedded in-process with the database. Best-guess for me would be if the Java security manager is turned on then enable default security for the database, whether you are in network server mode or embedded mode. If people want to tolerate the overhead of security manager calls in order to prevent malware in the JVM then they would also most likely also be willing to tolerate the additional overhead of Derby security by default. Just a thought... Cheers, Matt On 9/19/11 1:20 PM, José Ventura st.ne...@gmail.com wrote: (perhaps this has already been discussed in the devs' mailing list, if so, forgive my ignorance). I'm not sure whether making the default value on will actually improve security as a whole. If a developer hasn't given thought to security, there are plenty of other pitfalls that may compromise an application (e.g. where should I store the (previously unneeded yet now required) username and password?). On the other hand, if s/he did in fact think about security, then odds are that are a simple, concise documentation will point him/her to happily turn on the switch with minimum nuisance, and proceed to secure the rest of the application. @Roy: I believe that, since the change would happen in a next major release (11 vs. current 10.x), backwards compatibility wouldn't be *required* (but would certainly be *appreciated*). On Mon, Sep 19, 2011 at 4:55 PM, Rick Hillegas rick.hille...@oracle.com wrote: Hi Mike, Some comments inline... On 9/19/11 10:38 AM, Mike Matrigali wrote: I am not sure how it applies to all of these points, but I am wondering if secure by default should be implemented on a per database basis rather than a system level basis? It seems wierd that security could change based on how the next embedded startup set a flag. I think that it should behave like derby.database.sqlAuthorization: once it's been turned on it is stored in the database and you can't turn it off at the system level. I agree that it would be weird to let the next user subvert the security of your database by flipping a command line switch. What about having the property be part of what user requests at database creation time? And maybe allow some secure way either disable or enable it. The discussion could continue on what the default for a newly created database would be. At least for point 1-4 seems to make more sense, not sure about 5,6. I personally think many of these points make most sense for derby network server. I'm also concerned about the embedded database on a USB stick. I could argue that it is more vulnerable than the server-side database locked up in a machine room. While many possibly get in the way for many zero-admin embedded applications. I'm imagining that this change may be fairly unobtrusive. For an embedded database which has only one user (the dbo), the big change is that the dbo has to specify a username and password. There won't be any need to GRANT access to other users so (2) won't be noticed. Items (3) and (4) won't burden most applications. (5) and (6) are only issues for client/server usage. Since we have one codeline for the most part for both it is hard to have one default. I agree that a common default would be best. It will make it easier to reason about Derby's behavior and simplify our user guides. Thanks, -Rick Rick Hillegas wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on.
Re: Derby secure by default
Rick Hillegas wrote: I'm also concerned about the embedded database on a USB stick. I could argue that it is more vulnerable than the server-side database locked up in a machine room. Derby has one answer to this issue and that is encrypted databases. I don't think anything other than that is secure. Because if you lose ownership of the files anyone can use a version of the open source software to look at the data no matter what you do with authentication or authorization. I sort of doubt even file permissions would help if someone has physical control of the device and can mount it anywhere. Having said that, I don't want to also enable encryption by default for embedded derby. It is unnecessary for many applications and imposes performance degredation and application complexity. Historically Derby was never meant to be secure. It was designed to be embedded and for owning applications to handle security. Early on the issue of losing ownership of the files was considered and so encrytion was added. Eventually client/server was added and even later sql authorization, but it was not expected to be used in general for embedded applications. While many possibly get in the way for many zero-admin embedded applications. I'm imagining that this change may be fairly unobtrusive. For an embedded database which has only one user (the dbo), the big change is that the dbo has to specify a username and password. There won't be any need to GRANT access to other users so (2) won't be noticed. Items (3) and (4) won't burden most applications. (5) and (6) are only issues for client/server usage. In many cases I don't think this is true. I know users I work with currently run an embedded derby application as a number of different users and their current application does not use authentication or authorization. As with other files used by the application they manage access to db files as appropriate for their application. Since we have one codeline for the most part for both it is hard to have one default. I agree that a common default would be best. It will make it easier to reason about Derby's behavior and simplify our user guides. Thanks, -Rick Rick Hillegas wrote: The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
Rick Hillegas wrote: Hi Mike, Some comments inline... On 9/19/11 10:38 AM, Mike Matrigali wrote: I am not sure how it applies to all of these points, but I am wondering if secure by default should be implemented on a per database basis rather than a system level basis? It seems wierd that security could change based on how the next embedded startup set a flag. I think that it should behave like derby.database.sqlAuthorization: once it's been turned on it is stored in the database and you can't turn it off at the system level. I agree that it would be weird to let the next user subvert the security of your database by flipping a command line switch. I am trying to understand what happens when we change the default and a user upgrades to 11 and starts up on there existing database that has no authentication or authorization enabled. What is the proposed soft upgrade behavior? What is the proposed hard upgrade behavior? This is a development detail but what is proposed for the existing derby set of tests, which I have to assume are about 99% not authenticated or authorized? Would we implement a way to run them both ways? Convert them all or most to run under new default?
Re: Derby secure by default
roy.mi...@comcast.net wrote: Installing a new version should always be backward compatible and not break anything in existing applications. If things don't work this way, it's bound to be (unncessarily) disruptive to some, and especially those less sophisticated and less able to figure out and fix problems. I see no reason why anyone who wishes to utilize the new capabilities would have any problem with setting the new property when they are ready to do so. Security is obviously important, especially for networked applications. I think it's also important not to do anything that interferes with embedded applications designed to require ZERO administration. +1 I think that new features that rick is proposing are valuable to some set of Derby users, and welcome their inclusion in Derby. Having one flag to enable a set of secure oriented features also seems reasonable as long as users can still pick and choose if they don't want the complete set. I don't think they should be made the default in the current release or a future release. I believe zero admin upgrade/backward compatibility has been a great feature for Derby so far and we should do whatever we can to not break it going forward. It seems like applications that need this feature set can set the appropriate flag going forward and then do the work to properly configure authentication and authorization, ssl encryption passwords, and other server administration. Since there is extra work necessary to use these features it seems reasonable to put to work on these applications to set the flag rather than put the work on the zero-admin applications that do not need these features. By default Derby should be zero admin and thus default to not requiring this extra administration. *From: *Rick Hillegas rick.hille...@oracle.com *To: *Derby Discussion derby-user@db.apache.org *Sent: *Monday, September 19, 2011 12:39:07 PM *Subject: *Derby secure by default The Derby developers are considering introducing a single master security property. Turning this property on will enable most Derby security mechanisms: 1) Authentication - Will be on, requiring username/password credentials at connection time. Derby will supply a default authentication mechanism. 2) SQL authorization - Will be on, hiding a user's data from other people. In addition, Derby will support more SQL Standard protections for Java routines. 3) File permissions - Will be tightened as described by DERBY-5363. 4) PUBLIC -This keyword will not be allowed as a user name. 5) SSL/TLS encryption - Will shield client/server traffic. 6) Server administration - Will require credentials. When the property is off, Derby will behave as it does today: Authentication, authorization, and network encryption will be off, file permissions will inherit defaults from the account which runs the VM, PUBLIC will be a legal user name, and server administration won't need credentials. This new master property will make it easier to configure a more secure application. We want to introduce the property in an upcoming 10.x release, where it will default to being off. That means that it won't cause compatibility problems. Later on, we might change the default for this property so that it would normally be turned on. This would make Derby more secure out of the box at the cost of breaking existing applications. Many applications would need to explicitly turn the property off in order to run as they did previously. Release notes would document this behavioral change and we would bump the major release id from 10 to 11 in order to call attention to the change. We would like your feedback on this trade-off between security out of the box versus disruption. Should this extra security be enabled by default? Thanks, -Rick
Re: Derby secure by default
On 9/19/2011 1:20 PM, José Ventura wrote: I'm not sure whether making the default value on will actually improve security as a whole. If a developer hasn't given thought to security, there are plenty of other pitfalls that may compromise an application (e.g. where should I store the (previously unneeded yet now required) username and password?). On the other hand, if s/he did in fact think about security, then odds are that are a simple, concise documentation will point him/her to happily turn on the switch with minimum nuisance, and proceed to secure the rest of the application. I think this is a very good point. The claim of secure by default is a very strong claim and may give a false sense of overall security. Some things, like encryption and perhaps stricter security manager settings are not part of the default, but might be an important part of actually securing a particular application. I agree it is good for the application developer to plan security and for us to make it as easy as possible for them to do so from a Derby perspective. Perhaps the conversation of the default is premature. Perhaps we should first nail down the easy security knob and understand its behavior and usefulness and then discuss whether it should/could be the default. Kathey
