Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Mon, 29 Aug 2011 20:49:38 +0000 (UTC)
From: "Dag H. Wanvik (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: 
 <984879188.4931.1314650978087.JavaMail.tomcat@hel.zones.apache.org>
In-Reply-To: 
 <507378079.20088.1311980529620.JavaMail.tomcat@hel.zones.apache.org>
Subject: [jira] [Issue Comment Edited] (DERBY-5363) Tighten default
 permissions of DB files with >= JDK6
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-5363?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13093149#comment-13093149 ] 

Dag H. Wanvik edited comment on DERBY-5363 at 8/29/11 8:49 PM:
---------------------------------------------------------------

I am having pains with the property "derby.storage.useDefaultFilePermissions".

Some half digested ideas follow.

In the present code the property "derby.storage.useDefaultFilePermissions" is a dynamic, system level property. The discussion showed that we may want to handle this per database (do we really? but we can only persist values per database...) I also think it makes more sense to make this static, at least at the database level.

But let as assume, we want to persist it per database.  This begs the question whether this is really a system level property (e.g. to control derby.log and files created during tracing of DRDA protocol in the server) or a data base level property (all db files). If we persist this per database, we may need and additional property for system level files, or try to use some sensible defaults at that level.

To illustrate: we need to decide how to handle the following cases, here given with a possible treatment: The matrix elements
show the resulting value of the property, given the Derby deployment mode, the existing value of the property persisted for a database, and the system level property as specified when the VM started.

    system level files:
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  T    !
       ! other modes  !     T      !   F   !  T    !
       ---------------------------------------------

To explain, the three entries for CLI server here compute  as follows given values "unspec", "F" (false) and "T" (true) for the property. That is, when we started the server, we did not specify a value for the property (case 1), we specified it to "false" (case 2) or we specified it to "true" (case three). The resulting value for system level files  is "false", "false" and "true" respectively.
That is, when unspecified for CLI server mode, we default to restrictive permissions.


    new db, db level files
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  T    !
       ! other modes  !     T      !   F   !  T    !
       -------------------------------------------------

    existing db: no prop found persisted
         mode: \ prop   unspec.    F      T
       ---------------------!------------!-------!-------!
       ! CLI server      !     T        !   i/w !  T    !
       ! other modes  !     T        !   i/w !  T    !
       --------------------------------------------------

    existing db: found persisted   F  
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  i/w  !
       ! other modes  !     F      !   F   !  i/w  !
       -------------------------------------------------

    existing db: found persisted   T
         mode: \ prop   unspec.    F      T
       ---------------------!----------!--------!-------!
       ! CLI server      !     F      !   i/w !  T    !
       ! other modes  !     T      !   i/w !  T    !
       -------------------------------------------------

where "prop" means specified value of derby.storage.useDefaultFilePermissions and "i/w" means "ignore with warning or error".

Hmm, this is getting a bit messy..  :)


      was (Author: dagw):
    I am having pains with the property "derby.storage.useDefaultFilePermissions".

Some half digested ideas follow.

In the present code the property "derby.storage.useDefaultFilePermissions" is a dynamic, system level property. The discussion showed that we may want to handle this per database (do we really? but we can only persist values per database...) I also think it makes more sense to make this static, at least at the database level.

But let as assume, we want to persist it per database.  This begs the question whether this is really a system level property (e.g. to control derby.log and files created during tracing of DRDA protocol in the server) or a data base level property (all db files). If we persist this per database, we may need and additional property for system level files, or try to use some sensible defaults at that level.

To illustrate: we need to decide how to handle the following cases, here given with a possible treatment: The matrix elements
show the resulting value of the property, given the Derby deployment mode, the existing value of the property persisted for a database, and the system level property as specified when the VM started.

    system level files:
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  T    !
       ! other modes  !     T      !   F   !  T    !
       ---------------------------------------------

To explain, the three entries for CLI server here compute  as follows given values "unspec", "F" (false) and "T" (true) for the property. That is, when we started the server, we did not specify a value for the property (case 1), we specified it to "false" 8case 2) or we specified it to "true" (case three). The resulting value for system level files  is "false", "false" and "true" respectively.
That is, when unspecified for CLI server mode, we default to restrictive permissions.


    new db, db level files
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  T    !
       ! other modes  !     T      !   F   !  T    !
       -------------------------------------------------

    existing db: no prop found persisted
         mode: \ prop   unspec.    F      T
       ---------------------!------------!-------!-------!
       ! CLI server      !     T        !   i/w !  T    !
       ! other modes  !     T        !   i/w !  T    !
       --------------------------------------------------

    existing db: found persisted   F  
         mode: \ prop   unspec.    F      T
       ---------------------!-----------!-------!-------!
       ! CLI server      !     F      !   F   !  i/w  !
       ! other modes  !     F      !   F   !  i/w  !
       -------------------------------------------------

    existing db: found persisted   T
         mode: \ prop   unspec.    F      T
       ---------------------!----------!--------!-------!
       ! CLI server      !     F      !   i/w !  T    !
       ! other modes  !     T      !   i/w !  T    !
       -------------------------------------------------

where "prop" means specified value of derby.storage.useDefaultFilePermissions and "i/w" means "ignore with warning or error".

Hmm, this is getting a bit messy..  :)

  
> Tighten default permissions of DB files with >= JDK6
> ----------------------------------------------------
>
>                 Key: DERBY-5363
>                 URL: https://issues.apache.org/jira/browse/DERBY-5363
>             Project: Derby
>          Issue Type: Improvement
>            Reporter: Dag H. Wanvik
>         Attachments: derby-5363-basic-1.diff, derby-5363-basic-1.stat, permission-5.diff, permission-5.stat, permission-6.diff, permission-6.stat, z.sql
>
>
> Before Java 6, files created by Derby would have the default
> permissions of the operating system context. Under Unix, this would
> depend on the effective umask of the process that started the Java VM.
> In Java 6 and 7, there are methods available that allows tightening up this
> (File.setReadable, setWritable), making it less likely that somebody
> would accidentally run Derby with a too lenient default.
> I suggest we take advantage of this, and let Derby by default (in Java
> 6 and higher) limit the visibility to the OS user that starts the VM,
> e.g. on Unix this would be equivalent to running with umask 0077. More
> secure by default is good, I think.
> We could have a flag, e.g. "derby.storage.useDefaultFilePermissions"
> that when set to true, would give the old behavior.

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira