db-derby-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From chaa...@apache.org
Subject svn commit: r1596037 [6/13] - in /db/derby/docs/trunk: ./ src/security/
Date Mon, 19 May 2014 20:09:36 GMT
Added: db/derby/docs/trunk/src/security/cseccsecure866716.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure866716.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure866716.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure866716.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,51 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure866716" xml:lang="en-us">
+<title>Creating a boot password</title>
+<shortdesc>When you encrypt a database, you usually specify a boot password,
+which is an alphanumeric string used to generate the encryption key. (You can
+also specify an encryption key directly.)</shortdesc>
+<prolog></prolog>
+<conbody>
+<p>The length of the encryption key depends on the algorithm used:</p>
+<ul>
+<li>AES (128, 192, and 256 bits)</li>
+<li>DES (the default) (56 bits)</li>
+<li>DESede (168 bits)</li>
+<li>All other algorithms (128 bits)</li>
+</ul>
+<note>The boot password should have at least as many characters as number
+of bytes in the encryption key (56 bits=8 bytes, 168 bits=24 bytes, 128 bits=16
+bytes). The minimum number of characters for the boot password allowed by <ph
+conref="../conrefs.dita#prod/productshortname"></ph> is eight.</note>
+<p>It is a good idea not to use words that would be easily guessed, such as
+a login name or simple words or numbers. A boot password, like any password,
+should be a mix of numbers and uppercase and lowercase letters.</p>
+<p>You turn on and configure encryption and specify the corresponding boot
+password on the connection URL for a database when you create it:</p>
+<codeblock>jdbc:derby:encryptionDB1;create=true;dataEncryption=true;
+bootPassword=clo760uds2caPe</codeblock>
+<note>If you lose the boot password and the database is not currently
+booted, you will not be able to connect to the database any more. (If you know
+the current boot password, you can change it. See
+<xref href="tseccsecurenewkeyoverview.dita"/>.)</note>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure866716.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecure876908.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure876908.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure876908.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure876908.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,103 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure876908" xml:lang="en-us">
+<title>Guest access to search for DNs</title>
+<shortdesc>In an LDAP system, users are hierarchically organized in the
+directory as a set of entries. An <i>entry</i> is a set of name-attribute pairs
+identified by a unique name, called a DN (distinguished name).</shortdesc>
+<prolog></prolog>
+<conbody>
+<p>An entry is unambiguously identified by a DN, which is the concatenation of
+selected attributes from each entry in the tree along a path leading from the
+root down to the named entry, ordered from right to left. For example, a DN for
+a user might look like this:</p>
+<codeblock>cn=mary,ou=People,o=example.com
+
+uid=mary,ou=People,o=example.com</codeblock>
+<p>The allowable entries for the name are defined by the entry's
+<codeph>objectClass</codeph>.</p>
+<p>An LDAP client can bind to the directory (successfully log in) if it provides
+a user ID and password. The user ID must be a DN, the fully qualified list of
+names and attributes. This means that the user must provide a very long
+name.</p>
+<p>Typically, the user knows only a simple user name (for example, the first
+part of the DN above, <codeph>mary</codeph>). With
+<ph conref="../conrefs.dita#prod/productshortname"></ph>, you do not need the
+full DN, because an LDAP client
+(<ph conref="../conrefs.dita#prod/productshortname"></ph>) can go to the
+directory first as a guest or even an anonymous user, search for the full DN,
+then rebind to the directory using the full DN (and thus authenticate the
+user).</p>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> typically initiates
+a search for a full DN before binding to the directory using the full DN for
+user authentication. <ph conref="../conrefs.dita#prod/productshortname"></ph>
+does not initiate a search in the following cases:</p>
+<ul>
+<li>You have set <codeph>derby.authentication.ldap.searchFilter</codeph> to
+<codeph>derby.user</codeph>.</li>
+<li>A user DN has been cached locally for the specific user with the
+<codeph>derby.user.UserName</codeph> property.</li>
+</ul>
+<p>For more information, see
+"<codeph>derby.authentication.ldap.searchFilter</codeph>" in the
+<ph conref="../conrefs.dita#pub/citref"></ph>.</p>
+<p>Some systems permit anonymous searches; others require a user DN and
+password. You can specify a user's DN and password for the search with the
+properties listed below. In addition, you can limit the scope of the search by
+specifying a filter (definition of the object class for the user) and a base
+(directory from which to begin the search) with the properties listed
+below.</p>
+<ul>
+<li><codeph>derby.authentication.ldap.searchAuthDN (optional)</codeph>
+<p>Specifies the DN with which to bind (authenticate) to the server when
+searching for user DNs. This parameter is optional if anonymous access is
+supported by your server. If specified, this value must be a DN recognized by
+the directory service, and it must also have the authority to search for the
+entries.</p>
+<p>If not set, it defaults to an anonymous search using the root DN specified
+by the <codeph>derby.authentication.ldap.searchBase</codeph> property. For
+example:</p>
+<codeblock>uid=guest,o=example.com</codeblock></li>
+<li><codeph>derby.authentication.ldap.searchAuthPW</codeph> (optional)
+<p>Specifies the password to use for the guest user configured above to bind to
+the directory service when looking up the DN. If not set, it defaults to an
+anonymous search using the root DN specified by the
+<codeph>derby.authentication.ldap.searchBase</codeph> property.</p>
+<codeblock>myPassword</codeblock></li>
+<li><codeph>derby.authentication.ldap.searchBase</codeph> (optional)
+<p>Specifies the root DN of the point in your hierarchy from which to begin a
+guest search for the user's DN. For example:</p>
+<codeblock>ou=people,o=example.com</codeblock></li>
+</ul>
+<p>To narrow the search, you can specify a user's
+<codeph>objectClass</codeph>.</p>
+<ul>
+<li><codeph>derby.authentication.ldap.searchFilter</codeph> (optional)
+<p>Set <codeph>derby.authentication.ldap.searchFilter</codeph> to a logical
+expression that specifies what constitutes a user for your LDAP directory
+service. The default value of this property is
+<codeph>objectClass=inetOrgPerson</codeph>. For example:</p>
+<codeblock>objectClass=person</codeblock></li>
+</ul>
+<p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for details on all
+these properties.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure876908.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecure88690.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure88690.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure88690.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure88690.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,55 @@
+<?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure88690" xml:lang="en-us">
+<title>Encrypting databases on creation</title>
+<shortdesc>You configure a
+<ph conref="../conrefs.dita#prod/productshortname"></ph> database for encryption
+when you create the database by specifying attributes on the connection URL.</shortdesc>
+<prolog><metadata>
+<keywords><indexterm>encrypting databases<indexterm>on creation</indexterm></indexterm>
+<indexterm>databases<indexterm>encrypting, on creation</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<ul>
+<li>To enable encryption, use the <codeph>dataEncryption=true</codeph>
+attribute.</li>
+<li>To provide a key for the encryption, specify either the
+<codeph>bootPassword=<i>key</i></codeph> attribute or the
+<codeph>encryptionKey=<i>key</i></codeph> attribute.</li>
+</ul>
+<p>The following connection URL specifies a boot password:</p>
+<codeblock>jdbc:derby:encryptedDB;create=true;dataEncryption=true;
+bootPassword=DBpassword</codeblock>
+<p>The following URL specifies an encryption key:
+<codeblock>jdbc:derby:encryptedDB;create=true;dataEncryption=true;
+encryptionKey=6162636465666768</codeblock></p>
+<p>The default encryption algorithm is DES.</p>
+<p>You can specify an encryption provider and/or encryption algorithm
+other than the defaults by using the
+<codeph>encryptionProvider=<i>providerName</i></codeph> and
+<codeph>encryptionAlgorithm=<i>algorithm</i></codeph> attributes. See
+<xref href="cseccsecure31493.dita"/> and <xref href="cseccsecure67151.dita"/>
+for more information.</p>
+<p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for details on the
+connection URL attributes.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure88690.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecure90988.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure90988.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure90988.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure90988.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure90988" xml:lang="en-us">
+<title>Using signed jar files</title>
+<shortdesc>In a Java SE environment,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> can detect digital
+signatures on jar files. When attempting to load a class from a signed jar file
+stored in the database, <ph conref="../conrefs.dita#prod/productshortname"></ph>
+will verify the validity of the signature.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>jar files<indexterm>loading signed</indexterm></indexterm>
+<indexterm>signed jar files</indexterm></keywords>
+</metadata></prolog>
+<conbody>
+<note>The <ph conref="../conrefs.dita#prod/productshortname"></ph> class loader
+only validates the integrity of the signed jar file and verifies that the
+certificate has not expired. 
+<ph conref="../conrefs.dita#prod/productshortname"></ph> cannot ascertain
+whether the validity or identity of declared signer is correct. To validate
+identity, use a Security Manager (that is, an implementation of
+<codeph>java.lang.SecurityManager</codeph>). For details, see
+<xref href="csecjavasecurity.dita"/>.</note>
+<p>When loading classes from an application jar file in a Java SE environment,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> behaves as follows if
+the class is signed:</p>
+<ul>
+<li>Verifies that the jar file was signed using a X.509 certificate (that is,
+it can be represented by the class
+<codeph>java.security.cert.X509Certificate</codeph>). If not, throws an
+exception.</li>
+<li>Verifies that the digital signature matches the contents of the file. If
+not, throws an exception.</li>
+<li>Checks that the set of signing certificates are all valid for the current
+date and time. If any certificate has expired or is not yet valid, throws an
+exception.</li>
+<li>Passes the array of certificates to the <codeph>setSigners()</codeph> method
+of <codeph>java.lang.ClassLoader</codeph>. This allows security managers to
+obtain the list of signers for a class (using
+<codeph>java.lang.Class.getSigners</codeph>) and then validate the identity of
+the signers using the services of a Public Key Infrastructure (PKI).</li>
+</ul>
+<p>For more information about signed jar files, see <xref format="html"
+href="http://docs.oracle.com/javase/8/docs/technotes/guides/jar/jar.html"
+scope="external"/>.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure90988.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecure96815.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure96815.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure96815.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure96815.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure96815" xml:lang="en-us">
+<title>Requirements for <ph conref="../conrefs.dita#prod/productshortname"></ph>
+encryption</title>
+<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph> supports
+disk encryption and requires an encryption provider.</shortdesc>
+<prolog><metadata>
+<keywords><indexterm>Encryption<indexterm>providers</indexterm></indexterm>
+<indexterm>Data encryption<indexterm>providers</indexterm></indexterm></keywords>
+</metadata></prolog>
+<conbody>
+<p>An encryption provider implements the Java cryptography concepts. The Java
+Runtime Environment (JRE) for Java SE includes Java Cryptographic Extensions
+(JCE, part of the Java Cryptography Architecture) and one or more default
+encryption providers. For more information, see the <cite>Java Cryptography
+Architecture (JCA) Reference Guide</cite> at <xref format="html"
+href="http://docs.oracle.com/javase/8/docs/technotes/guides/security/crypto/CryptoSpec.html"
+scope="external"/>.
+</p>
+<p> The JRE determines the default encryption provider as follows:</p>
+<ul>
+<li>The JRE's provider is the default.</li>
+<li>If your environment for some reason does not include a provider, it must be
+specified.</li>
+</ul>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure96815.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecure97760.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecure97760.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecure97760.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecure97760.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,29 @@
+<?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecure97760" xml:lang="en-us">
+<title>Working with encryption</title>
+<shortdesc>This section describes using encryption in <ph conref="../conrefs.dita#prod/productshortname"></ph>.</shortdesc>
+<prolog><metadata>
+<keywords><indexterm>encryption<indexterm>working with</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody></conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecure97760.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecuredbowner.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecuredbowner.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecuredbowner.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecuredbowner.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,62 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecuredbowner" xml:lang="en-us">
+<title>Database Owner</title>
+<shortdesc>The term <i>Database Owner</i> refers to the current authorization
+identifier when the database is created, that is, the user creating the
+database. If you use NATIVE authentication, or if you manually enable or plan to
+enable SQL authorization, controlling the identity of the Database Owner becomes
+important.</shortdesc>
+<prolog><metadata><keywords>
+<indexterm>Database Owner</indexterm>
+<indexterm>Database Owner<indexterm>powers</indexterm></indexterm>
+<indexterm>Database Owner<indexterm>permissions</indexterm></indexterm>
+</keywords></metadata></prolog>
+<conbody>
+<p>When a database is created, the Database Owner of that database is implicitly
+set to the authorization identifier used in the connect operation that creates
+the database, for example, by supplying the URL attribute "user".  Note that
+this applies even if authentication is not (yet) enabled. In SQL, the built-in
+functions USER and the equivalent CURRENT_USER return the current authorization
+identifier.</p>
+<p>If the database is created <i>without</i> supplying a user (this is possible
+only if authentication is not enabled), the Database Owner is set to the default
+authorization identifier, "APP", which is also the name of the default schema.
+See "SET SCHEMA statement" in the
+<ph conref="../conrefs.dita#pub/citref"></ph> for details.</p>
+<p>The Database Owner has automatic SQL level permissions when SQL
+authorization is enabled. For more information, see
+<xref href="csecauthorfine.dita#csecauthorfine"></xref>.</p>
+<p>To further enhance security, when
+<i>both</i>&nbsp;<xref href="cseccsecure42374.dita">authentication</xref>
+and SQL authorization are enabled for a database,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> restricts some
+special powers to the Database Owner: only the Database Owner is allowed to
+shut down the database, to
+<xref href="tseccsecureunencrypteddb.dita">encrypt</xref> or
+<xref href="tseccsecurenewkeyoverview.dita">reencrypt</xref> the database, or to
+perform a full upgrade of the database. These powers cannot be delegated.</p>
+<p><note type="attention">There is currently no way of changing the
+Database Owner once the database is created. This means that if you plan to
+run with SQL authorization enabled, you should make sure to create the
+database as the user you want to be the owner.</note></p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecuredbowner.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecuredecryptdb.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecuredecryptdb.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecuredecryptdb.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecuredecryptdb.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,63 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecuredecryptdb" xml:lang="en-us">
+<title>Decrypting an encrypted database</title>
+<shortdesc>You can return an encrypted database to an unencrypted state by
+specifying attributes on the connection URL.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>encrypted databases<indexterm>decrypting</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<p>To decrypt an encrypted database, specify the
+<codeph>decryptDatabase=true</codeph> attribute in conjunction with either the
+<codeph>bootPassword=<i>key</i></codeph> attribute or the
+<codeph>encryptionKey=<i>key</i></codeph> attribute.</p>
+<p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for details on the
+connection URL attributes.</p>
+<note othertype="Recommendation" type="other">Ensure that you have enough free
+disk space before you decrypt a database. In addition to the disk space required
+for the unencrypted size of the database, temporary disk space is required to
+store the encrypted version of the data to restore the database to its encrypted
+state if the decryption is interrupted or returns errors. All of the temporary
+disk space is released back to the operating system after the database is
+decrypted.</note>
+<p>You must shut down the database before you decrypt it. An attempt to decrypt
+a booted database has no effect.</p>
+<p>If the database is configured with log archival, you must disable log
+archival in addition to shutting down the database before you can decrypt the
+database. You should also create a new backup of the database before you decrypt
+it, and create another after you decrypt it. For more information, see the
+section "Backing up and restoring databases" in the
+<ph conref="../conrefs.dita#pub/citadmin"></ph>, particularly "Roll-forward
+recovery".</p>
+<p>If any global transactions are in the prepared state after recovery, the
+database cannot be decrypted.</p>
+<p>If <xref href="cseccsecure42374.dita">authentication</xref>
+and <xref href="csecauthorfine.dita#csecauthorfine">SQL authorization</xref> are
+both enabled, the credentials of the
+<xref href="cseccsecuredbowner.dita">Database Owner</xref> must be supplied as
+well, since decryption is a restricted operation.</p>
+<p>After you decrypt the database, be sure to check for
+<codeph>SQLWarning</codeph>s. The decryption succeeded only if there were no
+<codeph>SQLWarning</codeph>s or <codeph>SQLException</codeph>s.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecuredecryptdb.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecuree.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecuree.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecuree.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecuree.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,87 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecuree" xml:lang="en-us">
+<title>Part Two: Configuring security for
+<ph conref="../conrefs.dita#prod/productshortname"></ph></title>
+<shortdesc>This part of the manual describes the specific tasks involved in
+securing <ph conref="../conrefs.dita#prod/productshortname"></ph>
+databases.</shortdesc>
+<prolog><metadata>
+<keywords><indexterm>user authentication<indexterm>definition</indexterm></indexterm>
+<indexterm>authentication<indexterm>definition</indexterm></indexterm>
+<indexterm>disk encryption<indexterm>definition</indexterm></indexterm>
+<indexterm>encrypting databases<indexterm>definition</indexterm></indexterm></keywords>
+</metadata></prolog>
+<conbody>
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> can be
+deployed in a number of ways and in a number of different environments, ranging
+from a single-user deployment for small-scale development and testing to a
+multi-user deployment of a large database. For all but the smallest deployments,
+however, it is essential to make the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> system secure.</p>
+<p>To secure a <ph conref="../conrefs.dita#prod/productshortname"></ph>
+database or databases, take the following steps.</p>
+<ol>
+<li>Understand the basic tasks involved in configuring security in a
+client-server environment or an embedded environment.
+<p>See <xref href="cseccsecure12392.dita"/> for details.</p></li>
+<li>Encrypt your databases.
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> provides ways to
+encrypt data stored on disk.</p>
+<p>For more information about encryption, see
+<xref href="cseccsecure24366.dita"/>.</p></li>
+<li>Sign any jar files that you use in your databases.
+<p><ph conref="../conrefs.dita#prod/productshortname"></ph> validates
+certificates for classes loaded from signed jar files.</p>
+<p>For more information about using signed jar files, see
+<xref href="cseccsecure90988.dita"/>.</p></li>
+<li>Encrypt network traffic with SSL/TLS.
+<p>SSL/TLS certificate authentication is also supported. See
+<xref href="csecssl.dita"/> for details.</p></li>
+<li>Understand the concept of identity in
+<ph conref="../conrefs.dita#prod/productshortname"></ph>.
+<p>See <xref href="cseccsecureidentity.dita"/> for details.</p></li>
+<li>Configure <i>authentication</i> by setting up users and passwords.
+<p>Authentication determines whether someone is a legal user. It establishes
+a user's identity. <ph conref="../conrefs.dita#prod/productshortname"></ph>
+verifies user names and passwords before permitting access to the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> system.</p>
+<p>For more information about authentication, see
+<xref href="cseccsecure42374.dita"/>.</p></li>
+<li>Configure <i>user authorization</i> for the system.
+<p>Authorization determines what operations can be performed by a user's
+<ph conref="../conrefs.dita#prod/productshortname"></ph> identity. 
+Authorization grants users or roles permission to read a database or to write
+to a database.</p>
+<p>For more information about authorization, see
+<xref href="csecauthorization.dita#csecauthorization"></xref>.</p></li>
+<li>Customize the default security policy.
+<p>For details, see
+<xref href="csecjavasecurity.dita#csecjavasecurity"></xref>.</p></li>
+<li>If necessary, restrict database file access to the operating system account
+that started the JVM.
+<p>For details, see <xref href="csecnetservfileperms.dita"/>.</p></li>
+</ol>
+<p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for information about
+many security-related properties and system procedures, as well as such
+statements as GRANT, REVOKE, CREATE ROLE, DROP ROLE, CREATE PROCEDURE, and
+CREATE FUNCTION.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecuree.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecuregrantrevokeaccess.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecuregrantrevokeaccess.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecuregrantrevokeaccess.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecuregrantrevokeaccess.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,119 @@
+<?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecuregrantrevokeaccess" xml:lang="en-us">
+<title>Using fine-grained user authorization</title>
+<shortdesc>When the SQL standard authorization mode is enabled, object owners
+can use the GRANT and REVOKE SQL statements to set the user privileges for
+specific database objects or for specific SQL actions. They can also use roles
+to administer privileges.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>user authorizations<indexterm>fine-grained</indexterm></indexterm>
+<indexterm>user authorizations<indexterm>granting</indexterm></indexterm>
+<indexterm>user authorizations<indexterm>revoking</indexterm></indexterm>
+<indexterm>user authorizations<indexterm>PUBLIC</indexterm></indexterm>
+<indexterm>GRANT statement<indexterm>overview</indexterm></indexterm>
+<indexterm>REVOKE statement<indexterm>overview</indexterm></indexterm>
+<indexterm>SQL standard authorization mode</indexterm>
+<indexterm>invoker rights<indexterm>versus definer rights</indexterm></indexterm>
+<indexterm>definer rights<indexterm>versus invoker rights</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<p>The GRANT statement is used to grant specific privileges to users or to
+roles, or to grant roles to users or to roles. The REVOKE statement is used to
+revoke privileges and role grants. The grant and revoke privileges are:<ul>
+<li>DELETE</li>
+<li>EXECUTE</li>
+<li>INSERT</li>
+<li>SELECT</li>
+<li>REFERENCES</li>
+<li>TRIGGER</li>
+<li>UPDATE</li>
+</ul></p>
+<p>When a table, view, function, or procedure is created, the person that
+creates the object is referred to as the <i>owner</i> of the object. Only the
+object owner and the <xref href="cseccsecuredbowner.dita">Database Owner</xref>
+have full privileges on the object. No other users have privileges on the
+object until the object owner grants privileges to them.</p>
+<p>Another way of saying that privileges on objects belong to the owner is to
+call them <i>definer rights</i>, as opposed to <i>invoker rights</i>. This is
+the terminology used by the SQL standard.</p>
+<p>See the <ph conref="../conrefs.dita#pub/citref"></ph> for more information on
+the GRANT and REVOKE statements.</p>
+<section><title>Public and individual user privileges</title>
+<p>The object owner can grant and revoke privileges for specific users, for
+specific roles, or for all users.</p>
+<p>The keyword PUBLIC is used to specify all users. When PUBLIC is specified,
+the privileges affect all current and future users. The privileges granted
+and revoked to PUBLIC and to individual users or roles are independent. For
+example, suppose that a SELECT privilege on table <codeph>t</codeph> is granted
+to both PUBLIC and to the user <codeph>harry</codeph>. The SELECT privilege is
+later revoked from user <codeph>harry</codeph>, but user <codeph>harry</codeph>
+has access to table <codeph>t</codeph> through the PUBLIC privilege.</p>
+<note othertype="Exception" type="other">When you create a view, trigger, or
+constraint, <ph conref="../conrefs.dita#prod/productshortname"></ph> first
+checks to determine if you have the required privileges at the user level.
+If you have the user-level privileges, the object is created and is dependent
+on that user-level privilege. If you do not have the required privileges at
+the user level, <ph conref="../conrefs.dita#prod/productshortname"></ph> checks
+to determine if you have the required privileges at the PUBLIC level. If you
+have the PUBLIC level privileges, the object is created and is dependent on
+that PUBLIC level privilege. After the object is created, if the privilege
+on which the object depends is revoked, the object is automatically dropped.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> does not try to
+determine if you have other privileges that can replace the privileges that are
+being revoked. 
+<dl>
+<dlentry>
+<dt>Example 1</dt>
+<dd>User <codeph>zhi</codeph> creates table <codeph>t1</codeph> and grants
+SELECT privileges to user <codeph>harry</codeph> on table <codeph>t1</codeph>.
+User <codeph>zhi</codeph> grants SELECT privileges to PUBLIC on table
+<codeph>t1</codeph>. User <codeph>harry</codeph> creates view
+<codeph>v1</codeph> with the statement <codeph>SELECT * from zhi.t1</codeph>.
+The view depends on the user-level privilege that user <codeph>harry</codeph>
+has on <codeph>t1</codeph>. Subsequently, user <codeph>zhi</codeph> revokes
+SELECT privileges from user <codeph>harry</codeph> on table <codeph>t1</codeph>.
+As a result, the view <codeph>harry.v1</codeph> is dropped.</dd>
+</dlentry>
+<dlentry>
+<dt>Example 2</dt>
+<dd>User <codeph>anita</codeph> creates table <codeph>t1</codeph> and grants
+SELECT privileges to PUBLIC. User <codeph>harry</codeph> creates view
+<codeph>v1</codeph> with the statement <codeph>SELECT * from anita.t1</codeph>.
+The view depends on the PUBLIC level privilege that user <codeph>harry</codeph>
+has on <codeph>t1</codeph>, since user <codeph>harry</codeph> does not have
+user-level privileges on table <codeph>t1</codeph> when he creates the view
+<codeph>harry.v1</codeph>. Subsequently, user <codeph>anita</codeph> grants
+SELECT privileges to user <codeph>harry</codeph> on table
+<codeph>anita.t1</codeph>. The view <codeph>harry.v1</codeph> continues to
+depend on the PUBLIC level privilege that user <codeph>harry</codeph> has on
+<codeph>t1</codeph>. When user <codeph>anita</codeph> revokes SELECT privileges
+from PUBLIC on table <codeph>t1</codeph>, the view <codeph>harry.v1</codeph> is
+dropped.</dd>
+</dlentry>
+</dl>
+<p>See <xref href="cseccsecureprivileges.dita"/> for more information.</p>
+</note>
+</section>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecuregrantrevokeaccess.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecureidentity.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecureidentity.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecureidentity.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecureidentity.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecureidentity" xml:lang="en-us">
+<title>Understanding identity in
+<ph conref="../conrefs.dita#prod/productshortname"></ph></title>
+<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph> provides two
+kinds of identity, <i>system-wide identity</i> and
+<i>database-specific identity</i>.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>identity<indexterm>system-wide</indexterm></indexterm>
+<indexterm>identity<indexterm>database-specific</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<section>
+<ul>
+<li>System-wide identity: Currently, any legal system-wide identity enjoys
+authorization to perform the following operations:
+<ul>
+<li>Create databases</li>
+<li>Restore databases</li>
+<li>Shut down the <ph conref="../conrefs.dita#prod/productshortname"></ph>
+engine</li>
+</ul>
+</li>
+<li>Database-specific identity: If you are a legal identity in a specific
+database, you may enjoy the following rights:
+<ul>
+<li>You can connect to that database, provided that coarse-grained connection
+authorization has not been set to <codeph>noAccess</codeph>.</li>
+<li>You can shut down that database, encrypt it, and upgrade it, provided that
+you are the <xref href="cseccsecuredbowner.dita">Database Owner</xref>.</li>
+<li>You can create your own SQL objects and write data to your own tables,
+provided that your coarse-grained connection authorization has not been set to
+<codeph>readOnlyAccess</codeph>.</li>
+<li>You can access other SQL objects, provided that the owners have granted you
+fine-grained SQL access to those objects, and provided you have not been limited
+by coarse-grained <codeph>readOnlyAccess</codeph>.</li>
+</ul>
+</li>
+</ul>
+<p>The distinction between fine-grained SQL authorization and coarse-grained
+connection authorization is described in
+<xref href="csecauthorization.dita#csecauthorization"></xref>.</p>
+</section>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecureidentity.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecurenativeauth.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecurenativeauth.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecurenativeauth.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecurenativeauth.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,75 @@
+<?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecurenativeauth" xml:lang="en-us">
+<title>Configuring NATIVE authentication</title>
+<shortdesc><ph conref="../conrefs.dita#prod/productshortname"></ph>'s simplest
+authentication mechanism is NATIVE authentication.</shortdesc>
+<prolog><metadata>
+<keywords><indexterm>user authentication<indexterm>NATIVE authentication</indexterm></indexterm>
+<indexterm>NATIVE authentication<indexterm>overview</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<p>When you use NATIVE authentication, user names and encrypted passwords are
+stored in a database. You can specify a dedicated credentials database
+for this purpose, or you can store the credentials in the same database you use
+for your application data. The credentials are stored in the SYSUSERS system
+table of the database.</p>
+<p>To configure NATIVE authentication, follow these steps.</p>
+<ol>
+<li>Use the <codeph>SYSCS_UTIL.SYSCS_CREATE_USER</codeph> system procedure to
+add credentials for the
+<xref href="cseccsecuredbowner.dita">Database Owner</xref>. Remember that the
+Database Owner is the user who created the database.</li>
+<li>Add credentials for other users.</li>
+<li>Shut down the database, then reboot it. When the database reboots, NATIVE
+authentication is enabled.</li>
+</ol>
+<p>For example, you can issue the following commands:</p>
+<codeblock><b>java org.apache.derby.tools.ij</b>
+ij version 10.11
+ij> <b>connect 'jdbc:derby:testdb;create=true;user=tquist';</b>
+ij> -- the Database Owner must be the first user you create
+<b>call SYSCS_UTIL.SYSCS_CREATE_USER( 'tquist', 'tquist' );</b>
+0 rows inserted/updated/deleted
+ij> -- now add other users
+<b>call SYSCS_UTIL.SYSCS_CREATE_USER( 'thardy', 'thardy' );</b>
+0 rows inserted/updated/deleted
+ij> <b>call SYSCS_UTIL.SYSCS_CREATE_USER( 'jhallett', 'jhallett' );</b>
+0 rows inserted/updated/deleted
+ij> <b>call SYSCS_UTIL.SYSCS_CREATE_USER( 'mchrysta', 'mchrysta' );</b>
+0 rows inserted/updated/deleted
+ij> -- shut down the database in order to turn on NATIVE authentication
+<b>connect 'jdbc:derby:testdb;shutdown=true';</b>
+ERROR 08006: Database 'testdb' shutdown.
+ij> -- these connection attempts fail because of bad credentials
+<b>connect 'jdbc:derby:testdb;user=tquist';</b>
+ERROR 08004: Connection authentication failure occurred.  Reason: Invalid authentication..
+ij> <b>connect 'jdbc:derby:testdb;user=thardy;password=tquist';</b>
+ERROR 08004: Connection authentication failure occurred.  Reason: Invalid authentication..
+ij> -- these connection attempts present good credentials, so they succeed
+<b>connect 'jdbc:derby:testdb;user=tquist;password=tquist';</b>
+ij(CONNECTION1)> <b>connect 'jdbc:derby:testdb;user=thardy;password=thardy';</b>
+ij(CONNECTION2)> <b>connect 'jdbc:derby:testdb;user=jhallett;password=jhallett';</b>
+ij(CONNECTION3)> <b>connect 'jdbc:derby:testdb;user=mchrysta;password=mchrysta';</b>
+</codeblock>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecurenativeauth.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecureprivileges.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecureprivileges.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecureprivileges.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecureprivileges.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,82 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecureprivileges" xml:lang="en-us">
+<title>Privileges on views, triggers, constraints, and generated columns</title>
+<shortdesc>Views, triggers, constraints, and generated columns operate with the
+privileges of the owner of the view, trigger, constraint, or generated
+column.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>privileges<indexterm>on views, triggers, constraints, and generated columns</indexterm></indexterm>
+<indexterm>permissions<indexterm>on views, triggers, constraints, and generated columns</indexterm></indexterm>
+<indexterm>views<indexterm>privileges on</indexterm></indexterm>
+<indexterm>triggers<indexterm>privileges on</indexterm></indexterm>
+<indexterm>constraints<indexterm>privileges on</indexterm></indexterm>
+<indexterm>generated columns<indexterm>privileges on</indexterm></indexterm>
+<indexterm>invoker rights<indexterm>versus definer rights</indexterm></indexterm>
+<indexterm>definer rights<indexterm>versus invoker rights</indexterm></indexterm>
+<indexterm>SQL standard authorization mode</indexterm></keywords>
+</metadata></prolog>
+<conbody>
+<p>For example, suppose that user <codeph>anita</codeph> wants to create a view
+using the following statement:</p>
+<codeblock>CREATE VIEW s.v(vc1,vc2,vc3)
+    AS SELECT t1.c1,t1.c2,f(t1.c3)
+    FROM t1 JOIN t2 ON t1.c1 = t2.c1 
+    WHERE t2.c2 = 5</codeblock>
+<p>User <codeph>anita</codeph> needs the following privileges to create the
+view:</p>
+<ul>
+<li>Ownership of the schema <codeph>s</codeph>, so that she can create something
+in the schema</li>
+<li>Ownership of the table <codeph>t1</codeph>, so that she can allow others
+to see columns in the table</li>
+<li>SELECT privilege on column <codeph>t2.c1</codeph> and column
+<codeph>t2.c2</codeph></li>
+<li>EXECUTE privilege on function <codeph>f</codeph></li>
+</ul>
+<p>When the view is created, only user <codeph>anita</codeph> has the SELECT
+privilege on it. User <codeph>anita</codeph> can grant the SELECT privilege on
+any or all of the columns of view <codeph>s.v</codeph> to anyone, even to users
+that do not have the SELECT privilege on <codeph>t1</codeph> or
+<codeph>t2</codeph>, or the EXECUTE privilege on <codeph>f</codeph>. User
+<codeph>anita</codeph> then grants the SELECT privilege on view
+<codeph>s.v</codeph> to user <codeph>harry</codeph>. When user
+<codeph>harry</codeph> issues a SELECT statement on the view
+<codeph>s.v</codeph>, <ph conref="../conrefs.dita#prod/productshortname"></ph>
+checks to determine if user <codeph>harry</codeph> has the SELECT privilege on
+view <codeph>s.v</codeph>.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> does not check to
+determine if user <codeph>harry</codeph> has the SELECT privilege on
+<codeph>t1</codeph> or <codeph>t2</codeph>, or the EXECUTE privilege on
+<codeph>f</codeph>.</p>
+<p>Privileges on triggers, constraints, and generated columns work the same way
+as privileges on views. When one of these objects is created,
+<ph conref="../conrefs.dita#prod/productshortname"></ph> checks that the owner
+has the required privileges. Other users do not need to have those privileges
+to perform actions on a view, trigger, constraint, or generated column.</p>
+<p>If the required privileges are revoked from the owner of a view, trigger,
+constraint, or generated column, the object is dropped as part of the
+REVOKE statement.</p>
+<p>Another way of saying that privileges on objects belong to the owner is to
+call them <i>definer rights</i>, as opposed to <i>invoker rights</i>. This is
+the terminology used by the SQL standard.</p>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecureprivileges.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecureroles.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecureroles.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecureroles.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecureroles.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,211 @@
+<?xml version="1.0" encoding="utf-8"?>
+ 
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecureroles" xml:lang="en-us">
+<title>Using SQL roles</title>
+<shortdesc>When the SQL standard authorization mode is enabled, object owners
+can use the SQL roles facility to administer privileges.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>access control system<indexterm>SQL2003</indexterm></indexterm>
+<indexterm>SQL standard authorization mode<indexterm>SQL roles</indexterm></indexterm>
+<indexterm>SQL roles<indexterm>using</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<p>SQL roles are useful for administering privileges when a database has many
+users. Roles provide a more powerful way to grant privileges to users' sessions
+than to grant privileges to each user of the database, which easily becomes
+tedious and error-prone when many users are involved. Roles do not in and of
+themselves give better database security, but used correctly, they facilitate
+better security. Only the
+<xref href="cseccsecuredbowner.dita">Database Owner</xref> can create, grant,
+revoke, and drop roles. However, object owners can grant and revoke privileges
+for those objects to and from roles, as well as to and from individual users and
+PUBLIC (all users).</p>
+<note><ph conref="../conrefs.dita#prod/productshortname"></ph> implements a
+subset of SQL roles. The fact that only the Database Owner can create, grant,
+revoke, and drop roles is an implementation restriction.</note>
+<section id="rolecreategrant"><title>Creating and granting roles</title>
+<p>Roles are available only when SQL authorization mode is enabled (that is,
+when NATIVE authentication is being used, or when the property
+<codeph>derby.database.sqlAuthorization</codeph> is explicitly set to
+<codeph>TRUE</codeph>).</p>
+<p>Old databases must be fully upgraded to at least Release 10.5 before roles
+can be used. See "Upgrades" in the
+<ph conref="../conrefs.dita#pub/citdevelop"></ph> for more information.</p>
+<p>If SQL authorization mode is enabled, the Database Owner can use the
+CREATE ROLE statement to create roles. The Database Owner can then use the GRANT
+statement to grant a role to one or more users, to PUBLIC, or to another role.
+</p>
+<p>A role A <i>contains</i> another role B if role B is granted to role A, or is
+contained in a role C granted to role A. Privileges granted to a contained role
+are inherited by the containing roles. So the set of privileges identified by
+role A is the union of the privileges granted to role A and the privileges
+granted to any contained roles of role A.</p>
+<p>For example, suppose the Database Owner issued the following statements:</p>
+<codeblock>create role reader;
+create role updater;
+create role taskLeaderA;
+create role taskLeaderB;
+create role projectLeader;
+grant reader to updater;
+grant updater to taskLeaderA;
+grant updater to taskLeaderB;
+grant taskLeaderA to projectLeader;
+grant taskLeaderB to projectLeader;</codeblock>
+<p>The roles would then have the following containment relationships:</p>
+<ul>
+<li>The <codeph>projectLeader</codeph> role contains the
+<codeph>taskLeaderA</codeph> and <codeph>taskLeaderB</codeph> roles.</li>
+<li>The <codeph>taskLeaderA</codeph> and <codeph>taskLeaderB</codeph> roles both
+contain the <codeph>updater</codeph> role.</li>
+<li>The <codeph>updater</codeph> role contains the <codeph>reader</codeph>
+role.</li>
+</ul>
+<p>In this case, the <codeph>projectLeader</codeph> role contains all the other
+roles and has all their privileges. If the Database Owner then revokes
+<codeph>updater</codeph> from <codeph>taskLeaderA</codeph>,
+<codeph>projectLeader</codeph> still contains that role through
+<codeph>taskLeaderB</codeph>.</p>
+<p>The SYSCS_DIAG.CONTAINED_ROLES diagnostic table function can be used to
+determine the set of contained roles for a role.</p>
+<p>Cycles are not permitted in role grants. That is, if a role contains another
+role, you cannot grant the container role to the contained role. For example,
+the following statement would not be permitted:</p>
+<codeblock>grant projectLeader to updater;</codeblock>
+</section>
+<section><title>Setting roles</title>
+<p>When a user first connects to
+<ph conref="../conrefs.dita#prod/productshortname"></ph>, no role is set, and
+the CURRENT_ROLE function returns null. During a session, the user can call the
+SET ROLE statement to set the current role for that session. The role can be
+any role that has been granted to the session's current user or to PUBLIC. To
+unset the current role, call SET ROLE with an argument of NONE. At any time
+during a session, there is always a current user, but there is a current role
+only if SET ROLE has been called with an argument other than NONE. If a current
+role is not set, the session has only the privileges granted to the user
+directly or to PUBLIC.</p>
+<p>For example, if the Database Owner created and granted the roles shown in the
+previous session, a user would have to issue a SET ROLE statement to have them
+take effect. Suppose a user issued the following statement:</p>
+<codeblock>SET ROLE taskLeaderA;</codeblock>
+<p>Assuming that the Database Owner had granted the <codeph>taskLeaderA</codeph>
+role to the user, the user would be allowed to set the role as shown and would
+have all the privileges granted to the <codeph>taskLeaderA</codeph>,
+<codeph>updater</codeph>, and <codeph>reader</codeph> roles.</p>
+<p>To retrieve the current role identifier in SQL, call the CURRENT_ROLE
+function.</p>
+<p>Within stored procedures and functions that contain SQL, the current role
+depends on whether the routine executes with invoker's rights or with definer's
+rights, as specified by the EXTERNAL SECURITY clause in the CREATE FUNCTION or
+CREATE PROCEDURE statements in the
+<ph conref="../conrefs.dita#pub/citref"></ph>. During execution, the current
+user and current role are kept on an authorization stack, which is pushed during
+a stored routine call.</p>
+<ul>
+<li>Within routines that execute with invoker's rights, the following applies:
+initially, inside a nested connection, the current role is set to that of the
+calling context. So is the current user. Such routines may set any role granted
+to the invoker or to PUBLIC.</li>
+<li>Within routines that execute with definer's rights, the following applies:
+initially, inside a nested connection, the current role is NULL, and the current
+user is that of the definer. Such routines may set any role granted to the
+definer or to PUBLIC.</li>
+</ul>
+<p>Upon return from the stored procedure or function, the authorization stack is
+popped, so the current role of the calling context is not affected by any
+setting of the role inside the called procedure or function.  If the stored
+procedure opens more than one nested connection, these all share the same
+(stacked) current role (and user) state. Any dynamic result set passed out of a
+stored procedure sees the current role (or user) of the nested context.</p>
+</section>
+<section><title>Granting privileges to roles</title>
+<p>Once a role has been created, both the Database Owner and the object owner
+can grant privileges on tables and routines to that role. You can grant the same
+privileges to roles that you can grant to users. Granting a privilege to a role
+implicitly grants privileges to all roles that contain that role. For example,
+if you grant delete privileges on a table to <codeph>updater</codeph>, every
+user in the <codeph>updater</codeph>, <codeph>taskLeaderA</codeph>,
+<codeph>taskLeaderB</codeph>, and <codeph>projectLeader</codeph> role will also
+have delete privileges on that table, but users in the <codeph>reader</codeph>
+role will not.</p>
+</section>
+<section><title>Revoking privileges from a role</title>
+<p>Either the Database Owner or the object owner can revoke privileges from a
+role.</p>
+<p>When a privilege is revoked from a role A, that privilege is no longer held
+by role A, unless A otherwise inherits that privilege from a contained role.</p>
+<p>If a privilege to an object is revoked from role A, a session will lose that
+privilege if it has a current role set to A or a role that contains A, unless
+one or more of the following is true:</p>
+<ul>
+<li>The privilege is granted directly to the current user</li>
+<li>The privilege is granted to PUBLIC</li>
+<li>The privilege is also granted to another role B in the current role's set of
+contained roles</li>
+<li>The session's current user is the Database Owner or the object owner</li>
+</ul>
+</section>
+<section><title>Revoking roles</title>
+<p>The Database Owner can use the REVOKE statement to revoke a role from a user,
+from PUBLIC, or from another role.</p>
+<p>When a role is revoked from a user, that session can no longer keep that
+role, nor can it take on that role in a SET ROLE statement, unless the role is
+also granted to PUBLIC. If that role is the current role of an existing session,
+the current privileges of the session lose any extra privileges obtained through
+setting that role.</p>
+<p>The default drop behavior is CASCADE. Therefore, all persistent objects
+(constraints, views and triggers) that rely on that role are dropped. Although
+there may be other ways of fulfilling that privilege at the time of the revoke,
+any dependent objects are still dropped. This is an implementation limitation.
+Any prepared statement that is potentially affected will be checked again on the
+next execute. A result set that depends on a role will remain open even if that
+role is revoked from a user.</p>
+<p>When a role is revoked from a role, the default drop behavior is also
+CASCADE. Suppose you revoke role A from role B. Revoking the role will have the
+effect of revoking all additional applicable privileges obtained through A from
+B. Roles that contain B will also lose those privileges, unless A is still
+contained in some other role C granted to B, or the privileges come through some
+other role. See <xref href="#cseccsecureroles/rolecreategrant"></xref> for an
+example.</p>
+</section>
+<section><title>Dropping roles</title>
+<p>Only the Database Owner can drop a role. To drop a role, use the DROP ROLE
+statement.</p>
+<p>Dropping a role effectively revokes all grants of this role to users and
+other roles.</p>
+</section>
+<section><title>Further information</title>
+<p>For details on the following statements, functions, and system table related
+to roles, see the <ph conref="../conrefs.dita#pub/citref"></ph>.</p>
+<ul>
+<li>CREATE ROLE statement</li>
+<li>SET ROLE statement</li>
+<li>DROP ROLE statement</li>
+<li>GRANT statement</li>
+<li>REVOKE statement</li>
+<li>CURRENT_ROLE function</li>
+<li>SYSCS_DIAG.CONTAINED_ROLES table function</li>
+<li>SYSROLES system table</li>
+</ul>
+</section>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecureroles.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/cseccsecuresqlauthupgrade.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/cseccsecuresqlauthupgrade.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/cseccsecuresqlauthupgrade.dita (added)
+++ db/derby/docs/trunk/src/security/cseccsecuresqlauthupgrade.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,65 @@
+<?xml version="1.0" encoding="utf-8"?>
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="cseccsecuresqlauthupgrade" xml:lang="en-us">
+<title>Upgrading an old database to use SQL standard authorization</title>
+<shortdesc>An old, unprotected database can be shielded with authentication and
+SQL authorization later on.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>upgrade</indexterm>
+<indexterm>SQL standard authorization mode</indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<section><title>Upgrading authentication and authorization</title>
+<p>To protect a single-user database and convert it to a shared, multi-user
+database, simply enable authentication and SQL authorization. To do this, first
+turn on user authentication as described in
+<xref href="cseccsecure42374.dita"/>. Make sure that you supply login
+credentials for the <xref href="cseccsecuredbowner.dita">Database Owner</xref>.
+In most single-user databases, the Database Owner is APP. However, the Database
+Owner could be some other user if the original database creation URL specified
+a user name; for details, see
+<xref href="cseccsecuredbowner.dita">Database Owner</xref>. If you are unsure
+about who owns the database, run the following query:</p>
+<codeblock>select authorizationid from sys.sysschemas where schemaname = 'SYS'</codeblock>
+<p>After enabling user authentication, turn on SQL authorization. To do this,
+connect to the database as the Database Owner and issue the following
+command:</p>
+<codeblock>call syscs_util.syscs_set_database_property( 'derby.database.sqlAuthorization', 'true' )</codeblock>
+<p>Now shut down the database to activate the new value of
+<codeph>derby.database.sqlAuthorization</codeph>. The next time you boot the
+database, it will be protected by authentication and SQL authorization.</p>
+</section>
+<section><title>Behavior of upgraded databases</title>
+<p>You will notice the following behavior changes in your upgraded database:</p>
+<ul>
+<li><b>Data</b>: Users can access data in their own schemas. However, users
+cannot access data in schemas owned by other users. In particular, other users
+cannot access data in schemas belonging to the Database Owner. The Database
+Owner may need to GRANT access to that data.</li>
+<li><b>Database Maintenance</b>: In a single-user database, anyone can run
+maintenance procedures to backup/restore and import/export data. In the upgraded
+multi-user database, only the Database Owner can perform these sensitive
+operations.</li>
+</ul>
+</section>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/cseccsecuresqlauthupgrade.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/csecembeddedperms.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecembeddedperms.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/csecembeddedperms.dita (added)
+++ db/derby/docs/trunk/src/security/csecembeddedperms.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,199 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="csecembeddedperms" xml:lang="en-us">
+<title>Running embedded <ph conref="../conrefs.dita#prod/productshortname"></ph>
+ with a security manager</title>
+<shortdesc>This section describes the permissions that should be granted to the
+codebase <codeph>derby.jar</codeph> to allow you to run embedded <ph
+conref="../conrefs.dita#prod/productshortname"></ph> with a security
+manager.</shortdesc>
+<prolog><metadata>
+<keywords>
+<indexterm>permissions<indexterm>granting to derby.jar</indexterm></indexterm>
+</keywords>
+</metadata></prolog>
+<conbody>
+<p>These permissions are also needed to run the Network Server, but the Network
+Server requires additional permissions as well.</p>
+<p>These permissions are listed approximately in the order shown in <xref
+href="rsecpolicysample.dita"/>. Some of the optional permissions are not
+included in <xref href="rsecpolicysample.dita"/>.</p>
+<section><title>Mandatory permissions</title><dl><dlentry>
+<dt>permission java.lang.RuntimePermission "createClassLoader"</dt>
+<dd>Mandatory. It allows
+<ph conref="../conrefs.dita#prod/productshortname"></ph> to execute SQL queries
+and supports loading class files from jar files stored in the database.</dd>
+</dlentry><dlentry>
+<dt>permission java.util.PropertyPermission "derby.*", "read"</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to read
+individual <ph conref="../conrefs.dita#prod/productshortname"></ph> properties
+set in the JVM system properties. If the action is denied, the properties set in
+the JVM system properties are ignored.</dd>
+</dlentry></dl></section>
+<section><title>Optional permissions</title><dl><dlentry>
+<dt>permission java.util.PropertyPermission "user.dir", "read"</dt>
+<dd>Permits access to the system directory value if
+<codeph>derby.system.home</codeph> is not set or no permission has been granted
+to read the <codeph>derby.system.home</codeph> property.</dd>
+</dlentry><dlentry>
+<dt>permission java.util.PropertyPermission "sun.arch.data.model", "read"</dt>
+<dd>If set by the JVM, this is the definite answer to whether the system is
+32-bit or 64-bit.</dd>
+</dlentry><dlentry>
+<dt>permission java.util.PropertyPermission "os.arch", "read"</dt>
+<dd>Used by <ph conref="../conrefs.dita#prod/productshortname"></ph> to
+determine if the system is 32-bit or 64-bit, if the system property
+<codeph>sun.arch.data.model</codeph> isn't set by the JVM.
+<ph conref="../conrefs.dita#prod/productshortname"></ph> has to recognize the
+value of <codeph>os.arch</codeph> to determine if the system is 32-bit or
+64-bit, and if the value isn't recognized, a heuristic will be used
+instead.</dd>
+</dlentry><dlentry>
+<dt>permission java.io.FilePermission "${derby.system.home}", "read,write"</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to determine
+the system directory when it is set by <codeph>derby.system.home</codeph> and
+create it if needed. If the system directory already exists, only the "read"
+permission needs to be granted.</dd>
+</dlentry><dlentry>
+<dt>permission java.io.FilePermission "${derby.system.home}${/}derby.properties",
+"read"</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to read the
+system properties file from the system directory.</dd>
+</dlentry><dlentry>
+<dt>permission java.io.FilePermission "${derby.system.home}${/}derby.log",
+"read,write,delete"</dt>
+<dt>permission java.io.FilePermission "${user.dir}${/}derby.log",
+"read,write,delete";</dt>
+<dd>Only one of these permissions is needed. Permits the application to read,
+write, and delete to the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> log file, unless the
+log has been redirected. (See the <codeph>derby.stream.error</codeph> properties
+in the <ph conref="../conrefs.dita#pub/citref"></ph> for more information.) If
+one of the requested valid actions is denied, the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> log will be
+<codeph>java.lang.System.err</codeph>.</dd>
+</dlentry><dlentry>
+<dt>permission java.security.SecurityPermission "getPolicy"</dt>
+<dd>You need this permission if you want to change the security policy on the
+fly and reload it into a running system. Given this permission, a System
+Administrator can reload the policy file by calling the
+<codeph>SYSCS_UTIL.SYSCS_RELOAD_SECURITY_POLICY</codeph> system procedure, which
+is described in the <ph conref="../conrefs.dita#pub/citref"></ph>.</dd>
+</dlentry><dlentry>
+<dt>permission javax.management.MBeanServerPermission "createMBeanServer";</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to create an
+MBean server. If the JVM running
+<ph conref="../conrefs.dita#prod/productshortname"></ph> supports the platform
+MBean server, <ph conref="../conrefs.dita#prod/productshortname"></ph> will
+automatically try to create such a server if it does not already exist. For
+details, see "Using Java Management Extensions (JMX) technology" in the
+<ph conref="../conrefs.dita#pub/citadmin"></ph>.</dd>
+</dlentry><dlentry>
+<dt>permission javax.management.MBeanPermission 
+"org.apache.derby.*#[org.apache.derby:*]", "registerMBean,unregisterMBean";</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to register
+and unregister its (JMX) MBeans. Such MBeans are associated with the domain
+<codeph>org.apache.derby</codeph>, which is also the prefix of the fully
+qualified class name of all
+<ph conref="../conrefs.dita#prod/productshortname"></ph> MBeans. For more
+information about the <ph conref="../conrefs.dita#prod/productshortname"></ph>
+MBeans, refer to the public API documentation of the package
+<codeph>org.apache.derby.mbeans</codeph> and its subpackages. It is possible to
+fine-tune this permission (for example, to allow access only to certain MBeans).
+To fine-tune this permission, see the API documentation for
+<codeph>javax.management.MBeanPermission</codeph> or the JMX Instrumentation
+and Agent Specification.</dd>
+</dlentry><dlentry>
+<dt>permission javax.management.MBeanTrustPermission "register";</dt>
+<dd>Trusts <ph conref="../conrefs.dita#prod/productshortname"></ph> code to be
+the source of MBeans and to register these in the MBean server.</dd>
+</dlentry><dlentry>
+<dt>permission java.lang.RuntimePermission "getProtectionDomain";</dt>
+<dd>This permission is needed if you want classpath information to be printed to
+<codeph>derby.log</codeph>.</dd>
+</dlentry><dlentry>
+<dt>permission java.sql.SQLPermission "callAbort";</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> code to call
+the <codeph>java.sql.Connection.abort</codeph> method. This permission must be
+granted both to the <ph conref="../conrefs.dita#prod/productshortname"></ph>
+JDBC driver (by granting it to <codeph>derby.jar</codeph> and
+<codeph>derbyclient.jar</codeph>) and to the application code that calls
+<codeph>Connection.abort()</codeph>. Do not grant this permission to application
+code unless you are certain that only superusers can invoke the code.</dd>
+</dlentry><dlentry>
+<dt>permission java.lang.RuntimePermission "accessUserInformation";</dt>
+<dt>permission java.lang.RuntimePermission "getFileStoreAttributes";</dt>
+<dd>These two permissions are needed when you are running with JDK 7 or higher
+and when the secure file mask settings are active (that is, when
+<codeph>derby.storage.useDefaultFilePermissions</codeph> is set to false, or
+when the server has been started from the command line (in which case secure
+file mask settings are active by default). See
+<xref href="csecnetservfileperms.dita"/> for details.</dd>
+</dlentry><dlentry>
+<dt>permission java.net.SocketPermission "localhost:389", "connect,resolve";</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> code to
+contact the LDAP server to perform authentication. This permission must be
+granted to <codeph>derby.jar</codeph>. Port 389 is the default LDAP port.</dd>
+</dlentry><dlentry>
+<dt>permission java.lang.RuntimePermission "setContextClassLoader"</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to set the
+context class loader for long running threads to null to avoid potential for
+class loader leaks in application server environments when the application
+server starts <ph conref="../conrefs.dita#prod/productshortname"></ph> in a
+custom class loader.</dd>
+</dlentry><dlentry>
+<dt>permission java.lang.RuntimePermission "getClassLoader"</dt>
+<dd> This permission is also needed when setting the context class loader to
+avoid class loader leaks. The class loader for the parent is saved and set to
+null before creation of the thread and restored afterwards.</dd>
+</dlentry><dlentry>
+<dt>permission java.lang.RuntimePermission "getStackTrace";</dt>
+<dt>permission java.lang.RuntimePermission "modifyThreadGroup";</dt>
+<dd>These two permissions are needed to allow extended diagnostics, specifically
+the stack traces of all threads, to be dumped to <codeph>derby.log</codeph> on
+severe errors and when the
+<codeph>derby.stream.error.extendedDiagSeverityLevel</codeph> property is set.
+See the documentation of this property in the
+<ph conref="../conrefs.dita#pub/citref"></ph> for details.</dd>
+</dlentry><dlentry>
+<dt>permission java.sql.SQLPermission "deregisterDriver";</dt>
+<dd>Allows <ph conref="../conrefs.dita#prod/productshortname"></ph> to
+deregister the driver. This permission is needed for system shutdown only on the
+Java SE 8 platform and higher, if system shutdown is invoked without the
+<codeph>deregister=false</codeph> connection URL attribute (see the
+<ph conref="../conrefs.dita#pub/citref"></ph> for details).</dd>
+</dlentry>
+</dl>
+</section>
+<section><title>Combining permissions</title>
+<p>The <xref href="rsecpolicysample.dita#rsecpolicysample"></xref>
+combines several <codeph>derby.system.home</codeph> permissions into one
+permission as follows:
+<codeblock>permission java.io.FilePermission "${derby.system.home}/-", "read,write,delete";</codeblock>
+This permission allows the
+<ph conref="../conrefs.dita#prod/productshortname"></ph> engine complete access
+to the system directory and any databases contained in the system directory.
+You will probably want to restrict these liberal permissions, which allow the
+server to backup/restore and export/import to or from any location in the local
+file system.</p>
+</section>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/csecembeddedperms.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/csecintro.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintro.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/csecintro.dita (added)
+++ db/derby/docs/trunk/src/security/csecintro.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,28 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="csecintro" xml:lang="en-us">
+<title>Part One: Introduction to database security</title>
+<shortdesc>This part of the manual provides a conceptual introduction to
+database security.</shortdesc>
+<prolog></prolog>
+<conbody>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/csecintro.dita
------------------------------------------------------------------------------
    svn:eol-style = native

Added: db/derby/docs/trunk/src/security/csecintrodefenses.dita
URL: http://svn.apache.org/viewvc/db/derby/docs/trunk/src/security/csecintrodefenses.dita?rev=1596037&view=auto
==============================================================================
--- db/derby/docs/trunk/src/security/csecintrodefenses.dita (added)
+++ db/derby/docs/trunk/src/security/csecintrodefenses.dita Mon May 19 20:09:33 2014
@@ -0,0 +1,46 @@
+<?xml version="1.0" encoding="utf-8"?>
+
+<!DOCTYPE concept PUBLIC "-//OASIS//DTD DITA Concept//EN"
+ "../dtd/concept.dtd">
+<!-- 
+Licensed to the Apache Software Foundation (ASF) under one or more
+contributor license agreements.  See the NOTICE file distributed with
+this work for additional information regarding copyright ownership.
+The ASF licenses this file to You under the Apache License, Version 2.0
+(the "License"); you may not use this file except in compliance with
+the License.  You may obtain a copy of the License at      
+
+   http://www.apache.org/licenses/LICENSE-2.0  
+
+Unless required by applicable law or agreed to in writing, software  
+distributed under the License is distributed on an "AS IS" BASIS,  
+WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.  
+See the License for the specific language governing permissions and  
+limitations under the License.
+-->
+<concept id="csecintrodefenses" xml:lang="en-us">
+<title>Defenses against security threats</title>
+<shortdesc>Defenses against threats can be divided into two
+categories.</shortdesc>
+<prolog></prolog>
+<conbody>
+<ul>
+<li><ph conref="../conrefs.dita#prod/productshortname"></ph> defenses</li>
+<li>Other defenses</li>
+</ul>
+<p>The following terms are useful in discussing these defenses.</p>
+<ul>
+<li><b>System Administrator</b>: This is the person who configures
+<ph conref="../conrefs.dita#prod/productshortname"></ph>'s system-wide behavior.
+Typically, this is a highly privileged user responsible for allocating machine
+resources, managing the network, configuring security, and actually launching
+the Virtual Machine (VM).</li>
+<li><b>Database Owner</b>: This is the person who creates and tends the
+databases needed by a particular application. Of course, the Database Owner
+could be the System Administrator.</li>
+<li><b>User</b>: This is a person authorized to use an application. This
+includes end-users, technical support engineers, and developers who maintain the
+application.</li>
+</ul>
+</conbody>
+</concept>

Propchange: db/derby/docs/trunk/src/security/csecintrodefenses.dita
------------------------------------------------------------------------------
    svn:eol-style = native



Mime
View raw message