[
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:42 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" 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.. :)
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 are "unspec", "F" (false) and
"T" (true). 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
