Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (herse.apache.org: local policy)
Date: Tue, 27 Feb 2007 09:05:35 -0800
From: Rick Hillegas <Richard.Hillegas@Sun.COM>
Subject: Re: broken network startup scripts
In-reply-to: <54ac72d70702261153n5018a630m8fe0038d5480dec9@mail.gmail.com>
Sender: Richard.Hillegas@Sun.COM
To: derby-dev@db.apache.org
Message-id: <45E464DF.2000803@sun.com>
MIME-version: 1.0
Content-type: text/plain; format=flowed; charset=ISO-8859-1
Content-transfer-encoding: 7BIT
References: <45E307FC.8090404@sun.com>
 <54ac72d70702261153n5018a630m8fe0038d5480dec9@mail.gmail.com>
User-Agent: Thunderbird 1.5.0.5 (X11/20060828)

Andrew McIntyre wrote:
> On 2/26/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
>> The network startup scripts are broken now, as a result of the work I am
>> doing on DERBY-2196. We decided that, to avoid giving customers a false
>> sense of security, the secure-by-default server should fail to come up
>> if the customer does not specify how they want to authenticate users.
>> Now when you run the network startup script, the script fails fast,
>> telling you that you have to specify an authentication scheme.
>>
>> How should we handle this?
>>
>> 1) Make the out-of-the-box server come up with Builtin authentication
>> and one distinguished user if authentication is otherwise not specified.
>> This distinguished system administrator would have a canonical name and
>> password.
>>
>> 2) Revisit our decision to require authentication. Instead, let the
>> server come up installing a security manager even though the customer
>> has not specified any authentication scheme.
>>
>> 3) Add the -noSecurityManager option to the server boot command.
>
> If the goal is backward compaibility, then (3) provides just that: the
> behavior of the previous version, but probably deserves at least
> printing a warning. Since user authentication and installing a
> security manager are not directly related, (2) is certainly doable,
> but from the secure-out-of-the box standpoint, it does not provide a
> secure environment, since anyone could connect to the server and
> manipulate any database resource. (1) seems like it would have some
> complicated issues to resolve: for example, to be really secure the
> user needs to have a way to remove this default user in such a way
> that just running the network server again does not bring it back,
> even if the system home is not set to the same location or you've
> moved the database and server to a different machine. How do you do
> that?
>
> There's also 4: leave it as-is and force the user to think about the
> security of their network server. They can still provide the
> -noSecurityManager option as an argument to the script if they just
> want to get the server started. I'm leaning in that direction at the
> moment.
>
> andrew
Thanks for the quick response, Andrew. If we go with (4), then we have 
to change our attitude about the startup scripts. Right now they work 
out-of-the-box. With approach (4), they no longer work out-of-the-box. 
Instead, they are templates which have to be customized. It would be 
nice to tell customers how to do this. What do you think: should we 
document this:

a) in comments in the scripts themselves
b) in the Admin Guide
c) in the Getting Started Guide
d) all of the above
e) something else

Thanks,
-Rick