db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dag H. Wanvik (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (DERBY-5363) Tighten default permissions of DB files with >= JDK6
Date Mon, 29 Aug 2011 20:25:37 GMT

    [ 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:24 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 entried for CLI server here are "unspec", "F" (false) and "T" (true).
The resulting value to use is "false", "false" and "true".
The 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    !
       ---------------------------------------------

    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

        

Mime
View raw message