db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rick Hillegas <Richard.Hille...@Sun.COM>
Subject Re: [jira] Commented: (DERBY-2109) System privileges
Date Tue, 09 Jan 2007 17:39:11 GMT
Daniel John Debrunner wrote:
> 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.
> Dan.
I like simple solutions and am happy with this approach.


View raw message