db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mamta Satoor" <msat...@gmail.com>
Subject Re: broken network startup scripts
Date Tue, 27 Feb 2007 17:45:16 GMT
How about if we have multiple scripts to start the network server with and
without secure by default? Down side of this is that users might feel
overwhelmed with multiple start network server scripts.

On the other hand, for the backward compatibility, do we need to have
scripts with pre-10.3 names? If so, then I think we are back to the original
problem as to what should be the behavior of startNetworkServer script?

Just my 2cents,

On 2/27/07, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> 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

View raw message