From derby-user-return-13893-apmail-db-derby-user-archive=db.apache.org@db.apache.org Fri Sep 2 21:38:06 2011
Return-Path:
X-Original-To: apmail-db-derby-user-archive@www.apache.org
Delivered-To: apmail-db-derby-user-archive@www.apache.org
Received: from mail.apache.org (hermes.apache.org [140.211.11.3])
by minotaur.apache.org (Postfix) with SMTP id BE4E6785C
for ; Fri, 2 Sep 2011 21:38:06 +0000 (UTC)
Received: (qmail 13903 invoked by uid 500); 2 Sep 2011 21:38:06 -0000
Delivered-To: apmail-db-derby-user-archive@db.apache.org
Received: (qmail 13855 invoked by uid 500); 2 Sep 2011 21:38:05 -0000
Mailing-List: contact derby-user-help@db.apache.org; run by ezmlm
Precedence: bulk
list-help:
list-unsubscribe:
List-Post:
List-Id:
Reply-To: "Derby Discussion"
Delivered-To: mailing list derby-user@db.apache.org
Received: (qmail 13848 invoked by uid 99); 2 Sep 2011 21:38:05 -0000
Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 21:38:05 +0000
X-ASF-Spam-Status: No, hits=2.2 required=5.0
tests=FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE,SPF_PASS,T_FRT_BEFORE
X-Spam-Check-By: apache.org
Received-SPF: pass (athena.apache.org: domain of roy.minet@comcast.net designates 76.96.62.40 as permitted sender)
Received: from [76.96.62.40] (HELO qmta04.westchester.pa.mail.comcast.net) (76.96.62.40)
by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 02 Sep 2011 21:37:58 +0000
Received: from omta24.westchester.pa.mail.comcast.net ([76.96.62.76])
by qmta04.westchester.pa.mail.comcast.net with comcast
id TvSj1h0051ei1Bg54xdefs; Fri, 02 Sep 2011 21:37:38 +0000
Received: from sz0138.wc.mail.comcast.net ([76.96.58.202])
by omta24.westchester.pa.mail.comcast.net with comcast
id Txde1h00a4MnWwC3kxdedX; Fri, 02 Sep 2011 21:37:38 +0000
Date: Fri, 2 Sep 2011 21:37:37 +0000 (UTC)
From: Roy.Minet@comcast.net
To: Derby Discussion
Message-ID: <1214250206.834872.1314999457902.JavaMail.root@sz0138a.westchester.pa.mail.comcast.net>
In-Reply-To: <4E611302.30800@oracle.com>
Subject: Re: Opinions on new security feature requested
MIME-Version: 1.0
Content-Type: multipart/alternative;
boundary="----=_Part_834871_383690093.1314999457901"
X-Originating-IP: [174.54.64.45]
X-Mailer: Zimbra 6.0.10_GA_2709 (ZimbraWebClient - IE8 (Win)/6.0.10_GA_2697)
------=_Part_834871_383690093.1314999457901
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
Unless it is completely unavoidable, it should be possible to install=C2=A0=
a later version AND NOT BREAK AN EXISTING APPLICATION.=C2=A0 To do so is ru=
de and can be very disruptive.=20
----- Original Message -----
From: "Dag H. Wanvik" =20
To: "Derby Discussion" =20
Sent: Friday, September 2, 2011 1:31:46 PM=20
Subject: Opinions on new security feature requested=20
Hi folks,=20
we are always working to make Derby more secure; in this day and age,=20
security is ever more on people's minds for obvious reasons;=20
IT systems are everywhere and the bad guys never tire of finding new=20
holes to break them. Up till now, Derby creates database files and logs=20
using the default operating system permission in effect. On Unix/linux=20
this is controlled by the umask of the process starting the Derby=20
engine, be in embedded or a standalone Derby network server. Similarly=20
on Windows, NTFS has a security model can be configured to give various=20
default permissions.=20
Now, often the defaults will allow other (than the one starting the VM)=20
OS users the permissions to read and possibly write to the database=20
files. This can be intention to allow several users to boot the same=20
(shared) database), or it can be accidental. In DERBY-5363 we have been=20
discussion use cases and scenarios for when it would be desirable to let=20
Derby be more secure than the default permissions. Other database also=20
do this, e.g. PostGreSQL, MS SQL server.=20
Typically, only the OS user creating the database would have access=20
(default behavior) unless one told the database to be lax and not worry=20
about tightening up the default OS permissions.=20
Obviously, one can achieve the same restrictive permissions, by setting=20
the umask to 0077 on Unix, or tweak the NTFS settings similarly=20
(Windows), but this requires some care and presumes that the users=20
remembers to do so (many people don't grok the NTFS security model..)=20
To be clear, one would be able to enable/disable this extra security by=20
providing Derby with a property setting, so the question is really what=20
is the msot appropriate default: use lax permissions (rely on the user=20
having tightened up be fore starting the VM), or use the new proactive=20
secure settings proposed in DERBY-5363.=20
Secure default pros:=20
- users will get better security by default. If one needs to share the=20
database files, one can use a property to get old, lax behavior.=20
- no need to change startup scripts to get better security=20
Secure default cons:=20
- upwards compatibility: if an installation relies on sharing database=20
files, on would have to start using a property after upgrading.=20
- requires at least Java 6 (on Unix), Java 7 on Windows/NTFS to work (an=20
incentive to upgrade, though :-)=20
In the discussion it as been suggested that many deployments, especially=20
of embedded Derby, rely on several OS users having permissions, so=20
changing the default Derby behavior would cause upgrade issues. Probably=20
for most client/server deployments, where the server is started from the=20
command line, it would be the same OS user starting the Derby server=20
every time. In mixed deployments (embedded, but the server is sometimes=20
started via the API), the latter may not hold true.=20
A possible trade-off between the concerns would thus be to start=20
embedded with the exisiting, lax permissions by default, but start the=20
server from the command line with a secure (restrictive) default. In=20
both cases, one would get the opposite behavior by providing a system=20
property on VM startup.=20
Before we settle the discussion on this, it would be good to hear what=20
you think! Thanks!=20
Dag=20
------=_Part_834871_383690093.1314999457901
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: quoted-printable
<=
div style=3D'font-family: Arial; font-size: 12pt; color: #000000'>Unless it=
is completely unavoidable, it should be possible to install a later v=
ersion AND NOT BREAK AN EXISTING APPLICATION. To do so is rude and ca=
n be very disruptive.

we are always working to make Derby =
more secure; in this day and age, security is ever more on people's min=
ds for obvious reasons;IT systems are everywhere and the bad guys never=
tire of finding new holes to break them. Up till now, Derby creates da=
tabase files and logs using the default operating system permission in =
effect. On Unix/linux this is controlled by the umask of the process st=
arting the Derby engine, be in embedded or a standalone Derby network s=
erver. Similarly on Windows, NTFS has a security model can be configure=
d to give various default permissions.

Now, often the defaults w=
ill allow other (than the one starting the VM) OS users the permissions=
to read and possibly write to the database files. This can be intentio=
n to allow several users to boot the same (shared) database), or it can=
be accidental. In DERBY-5363 we have been discussion use cases and sce=
narios for when it would be desirable to let Derby be more secure than =
the default permissions. Other database also do this, e.g. PostGreSQL, =
MS SQL server.

Typically, only the OS user creating the database wou=
ld have access (default behavior) unless one told the database to be la=
x and not worry about tightening up the default OS permissions.Obvi=
ously, one can achieve the same restrictive permissions, by setting the=
umask to 0077 on Unix, or tweak the NTFS settings similarly (Windows),=
but this requires some care and presumes that the users remembers to d=
o so (many people don't grok the NTFS security model..)

To be clear,=
one would be able to enable/disable this extra security by providing D=
erby with a property setting, so the question is really what is the mso=
t appropriate default: use lax permissions (rely on the user having tig=
htened up be fore starting the VM), or use the new proactive secure set=
tings proposed in DERBY-5363.

Secure default pros:- users will g=
et better security by default. If one needs to share the database files=
, one can use a property to get old, lax behavior.- no need to change s=
tartup scripts to get better security

Secure default cons:- upwa=
rds compatibility: if an installation relies on sharing database files,=
on would have to start using a property after upgrading.- requires at =
least Java 6 (on Unix), Java 7 on Windows/NTFS to work (an incentive to=
upgrade, though :-)

In the discussion it as been suggested that man=
y deployments, especially of embedded Derby, rely on several OS users h=
aving permissions, so changing the default Derby behavior would cause u=
pgrade issues. Probably for most client/server deployments, where the s=
erver is started from the command line, it would be the same OS user st=
arting the Derby server every time. In mixed deployments (embedded, but=
the server is sometimes started via the API), the latter may not hold =
true.

A possible trade-off between the concerns would thus be to sta=
rt embedded with the exisiting, lax permissions by default, but start t=
he server from the command line with a secure (restrictive) default. In=
both cases, one would get the opposite behavior by providing a system =
property on VM startup.

Before we settle the discussion on this,=
it would be good to hear what you think! Thanks!