Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Received-SPF: pass (athena.apache.org: domain of david.vancouvering@gmail.com
 designates 64.233.166.178 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=beta;
        h=received:message-id:date:from:sender:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references:x-google-sender-auth;
        b=E/dnXjk9/ckUP/OICTMr/VNLTWkIda571QLziSm3DMMxXUmFUcntLQQcOLC90BX/w7gDo3E6ystrz7iMAXNBOzLssjWS7IS0K6dVhPpct1Zr/s22OLd2/q0fnUHuidBbClhoS26nQAcDhdD9PruHcpFT/4/lbef8J1f8Qb1NANk=
Message-ID: <56a83cd00711071451q47556f2bk2cac2d8d0dad92af@mail.gmail.com>
Date: Wed, 7 Nov 2007 17:51:42 -0500
From: "David Van Couvering" <david@vancouvering.com>
Sender: david.vancouvering@gmail.com
To: derby-dev@db.apache.org
Subject: Re: Installing a SecurityManager by default when the server boots
In-Reply-To: <47320BAE.60609@sun.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <47320BAE.60609@sun.com>

IMHO, if we are breaking a lot of existing applications, then it was
not a compatible change, and needs to be turned off.  I understand the
value of "secure by default' but I think this has to be balanced
against the value of Derby as a very quickly easy to use and run
database which makes it a favorite of developers.  If it becomes too
security-heavy it loses one of its key value propositions.

Those who want to deploy in production and are worried about security,
we should make it very easy to turn on the security manager, e.g. with
a single flag in the network server startup command.

David

On Nov 7, 2007 2:02 PM, Rick Hillegas <Richard.Hillegas@sun.com> wrote:
> As of release 10.3, when you boot the network server from the command
> line, the server installs a Java SecurityManager with a default policy.
> This change (DERBY-2196) limits the ability of hackers, connecting from
> arbitrary machines, to use Derby to corrupt the environment in which it
> is running. In addition, this change provides a foundation on which we
> can add more security features incrementally. As a result of this
> change, we have learned more about how Derby behaves when run under a
> SecurityManager--that in turn, has helped us discover more permissions
> which we need to add to the template used as a starting point for
> configuring a Derby security policy.
>
> Unfortunately, this change has proved painful to some users. See, for
> instance, DERBY-3086 and the ongoing discussion on DERBY-3083.
>
> Now that we have some experience with the 10.3 release, I would like to
> ask the community to review the wisdom of this change. Do we still think
> that this is the correct default behavior? Or should we consider turning
> off this feature in the upcoming 10.3 maintenance release?
>
> Thanks,
> -Rick
>