db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daniel John Debrunner <...@apache.org>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Tue, 09 Jan 2007 15:08:49 GMT
Rick Hillegas wrote:
> Daniel John Debrunner wrote:
>> Rick Hillegas wrote:
>>> I have taken a stab at describing various security expectations which 
>>> customers might have and also how we could balance these expectations 
>>> against the desire to run the network server "secure by default". The 
>>> following wiki page addresses these issues:
>>>    http://wiki.apache.org/db-derby/SecurityExpectations
>> With the Basic policy some thought needs to be put into other 
>> resources/tasks:
>>  backup of a database
>>  restore of a database (?)
>>  import/export of data
>>  installing/replacing jar files
>> The described policy would mean all of those file resources need to be 
>> placed in the system home.
>> Dan.
> Thanks, Dan. I don't have any inspired ideas here. We could introduce a 
> new property, say, "derby.io.directories". This would resolve to a 
> classpath-like list of directories, that is, a list of directories 
> separated by the operating-system-specific separator (; or :). The 
> meaning of this property would be "Derby has read and write access to 
> all file-system trees rooted in these directories." At network startup, 
> the Basic policy file could grant read/write access to all of these trees.
> We could introduce extra granularity here. E.g., separate properties for 
> read access and write access; or separate properties for backup/restore, 
> import/export, and jar loading. However, I would err on the side of 
> keeping this simple. If a customer needs greater granularity, then they 
> can customize the Basic policy themselves.
> Your question prompted me to consider the following other loose-end: We 
> probably want to minimize upgrade problems for customers who have put 
> their logs on separate devices. In constructing the Basic policy, we 
> could walk all of the immediate subdirectories under derby.system.home, 
> looking for the service.properties files there and then grant 
> read/write/delete access to all directories identified by the logDevice 
> property stored in those service.properties files. I don't think this 
> would catch all of the cases but it might be helpful. Alternatively, it 
> might be overkill. What do you think?

A really simple solution to these would be to grant permission in the 
Basic policy to derby.jar to read/write/delete to '<<ALL FILES>>'. On 
windows/unix/linux systems the os file permissions will be in play and 
the accessibility to files by derby would match other client/server 
database systems.

Then as you say, anyone wanting finer granularity can write their own 
policy file.


View raw message