Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (nike.apache.org: local policy)
Message-ID: <4C931841.3020006@oracle.com>
Date: Fri, 17 Sep 2010 09:26:57 +0200
From: Kristian Waagan <kristian.waagan@oracle.com>
User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US;
 rv:1.9.2.7) Gecko/20100817 Thunderbird/3.1.1
MIME-Version: 1.0
To: derby-dev@db.apache.org
Subject: Re: Purpose of OSReadOnlyTest (DERBY-3837)
References: <4C91FA76.1010100@oracle.com>	<4C922DC4.7090306@gmail.com>
	<wjo8lj71r9e1.fsf@oracle.com>
 <AANLkTinM-QQ8jAyyCLGCDxu8q=kcJXa+10UHxjWkxotv@mail.gmail.com>
In-Reply-To: <AANLkTinM-QQ8jAyyCLGCDxu8q=kcJXa+10UHxjWkxotv@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

  On 16.09.10 19:02, Myrna van Lunteren wrote:
> On Thu, Sep 16, 2010 at 8:33 AM, Knut Anders Hatlen
> <knut.hatlen@oracle.com>  wrote:
>> Bryan Pendleton<bpendleton.derby@gmail.com>  writes:
>>
>>>> Since the comment in DERBY-3837 says the purpose of the test is to test
>>>> operation on read-only media, do you agree that we should make the
>>>> database directory truly read-only?
>>> +1.
>>>
>>> Thanks for tracking this down, and for the detailed description. Very
>>> interesting!
>> I agree. Having a database that's partly read-only and partly writable
>> doesn't sound like a use case we would want to support, so +1 to making
>> the database in the test truly read-only.
>>
>>>> And while I'm at it, I might want to move some of the file-system
>>>> helper methods into PrivilegedFileOpsForTests. The motivating factor
>>>> is that when a removal of a directory fails (recursive delete), it may
>>>> be useful to see which files couldn't be deleted. The question is if
>>>> it is okay to add a public static persistent recursive delete method
>>>> running in a privileged block to the test code?
>> You're asking because it's considered bad security practise to have
>> public helper methods doing privileged operations, right? If I
>> understand correctly, it will only be a security risk if someone runs
>> their production server with derbyTesting.jar in the classpath and has
>> granted delete permissions to derbyTesting.jar. I don't think that's
>> something we need to be concerned with in the test code.
>>
>> --
>> Knut Anders
>>
> I agree also to making the db fully read-only. Thanks for the analysis!
>
> I thought it would be obvious that derbyTesting.jar has no place in a
> production system...If you make this change to the helper method, do
> we need to document somewhere that the derbyTesting.jar opens up
> security issues or would it be obvious enough?

Hi Myrna,

I think it's obvious enough - don't make testing/debug code accessible 
in a production environment.

We already have file methods in there that are public static, but none 
of them delete files. If you fire off what I call "persistent recursive 
delete", it will try to delete all files in the specified path and it 
will not stop until it has tried to delete every single file and 
directory in the specified path. Of course, it's no more dangerous than 
writing 'rm -Rf <some-path>', except that the visibility is poorer. So, 
during testing, you do not want to point the method at your home 
directory and run without a security manager...

I'll see if I can add some kind of safeguard to isolate the method to 
the base test directory - the test framework should limit its file 
activities to that directory in any case. This will reduce the chances 
of causing havoc for an unfortunate Derby developer running with a 
misconfigured  or no security manager.

I logged DERBY-4804 to track the work.


@Knut
Yes, that's the reason why I ask - and I do feel I'm being rather 
cautious in this case :)


Thanks,
-- 
Kristian

> Myrna