I agree, changing the default policy file as Dan suggests does not
seem to be backward compatible.
I believe it would be worthwhile to publicize the decision to go with
(3) and the reasons why to the derby-user list. At least way we have
given our users a *chance* to say something one way or the other.
I may also do a quick blog about this and I can see what the feedback
there is like.
Thanks for listening!
David
On 6/1/07, Rick Hillegas <[EMAIL PROTECTED]> wrote:
Daniel John Debrunner wrote:
> Rick Hillegas wrote:
>> Thanks to Dan and David for your advice. Some more musings follow:
>>
>> David Van Couvering wrote:
>>> I am also torn between 2 and 3 but am leaning towards 2, especially if
>>> we document this is what we should do.
>>>
>>> Does Derby 10.3 have a beta period? If we can get a strong amount of
>>> users testing Derby 10.3 in beta we might get some good feedback if we
>>> go with option 2. If we start with 3 from the get-go, nobody would
>>> give us feedback (as it continues to work the way it did in 10.2), but
>>> we could be complicit in letting users expose themselves in a
>>> dangerous way.
>> Our release process doesn't factor in what I would call a beta test.
>> To my way of thinking, a real beta program would require a lot of
>> preparation, which we haven't done, and a lot of monitoring, which we
>> haven't planned.
>>
>> In short, I don't think our release process will give you the
>> feedback you want here. Possibly we would get quick, negative
>> feedback that (2) is the wrong approach. But I don't think we'll get
>> sufficient feedback to feel confident that (2) is the right approach.
>>>
>>> Like I said, if you're making your DB available on machines other than
>>> localhost, you are running in a non-development mode. I imagine the
>>> following scenario where I am your standard IT guy eating donuts in
>>> the server room:
>>>
>>> - I upgrade to 10.3 in a staging area (anyone who does a live upgrade
>>> without testing is definitely on the FAR edge of the bell curve)
>>> - 10.3 doesn't start up. WTF?
>>> - I read the error log. It explains why it didn't start up, what the
>>> risk is, and what you can do about it (explicitly turn off
>>> authentication or enable authentication)
>>>
>>> The user then has the choice. If his applications just don't do any
>>> authentication and it's a big change to modify the apps, then I can
>>> explicitly turn off authentication using
>>> derby.connection.requireAuthentication = false. But now I am aware of
>>> my risk. I can make plans to enable authentication in my apps and get
>>> on the security bandwagon.
>> I can see that many applications would fit this profile. I am
>> worried, however, about other applications which have been lulled
>> into a laxer process by Cloudscape/Derby's long track record of
>> painless upgrades.
>>>
>>> At least we (the Derby team) won't silently let users expose
>>> themselves -- we've given them their warning and now they are on their
>>> own.
>>>
>>> So, my 2 cents: go with number 2. A gentle slap in the face, and they
>>> can make their choice. One caveat: the error message needs to be
>>> *very* clear with *why* we did this (describe the exposure) and *what*
>>> the user can do about it (explicitly enable or disable
>>> authentication).
>>>
>>> David
>> I continue to be inclined to go with (3). The original issue
>> (DERBY-2196) was a request to install a security manager if the user
>> forgot to. I still think that's a good idea by itself. The follow-on
>> request was to stop giving the user a false sense of security. I
>> think that's a broader issue, some of whose details are mentioned by
>> DERBY-1056. Given the strong reaction to this email thread, our
>> inability to measure the residual exposure, and the lateness in the
>> day, I think that we should separate the two issues.
>>
>> I volunteer to do (3).
>
> With 3) can we restrict the file permissions in the default policy
> file. Currently it is:
>
> permission java.io.FilePermission "${derby.system.home}${/}-",
> "read,write,delete";
> permission java.io.FilePermission "<<ALL FILES>>", "read,write,delete";
>
> The <<ALL FILES>> is dangerous if the server is running without
> authentication and listening to remote clients (as 3) allows).
> (Just imagine if the server is started as super-user!)
Hi Dan,
I agree that this is a dangerous permission. According to the comment on
this permission, it is phrased broadly so that we don't break customer
scripts which import/export tables, backup/restore databases, and load
jar files.
>
> How about just
>
> permission java.io.FilePermission "${derby.system.home}${/}-",
> "read,write,delete";
> permission java.io.FilePermission "${java.io.tmpdir}${/}-",
> "read,write,delete";
>
> This would at least limit access to the derby.system.home and temp dirs.
This will work for existing customers who
import/export/backup/restore/loadJars to and from these directory trees.
I am worried, in particular, that customers may not typically
backup/restore to/from these directories. I think we would be
introducing a significant incompatibility.
The comment on the permission urges the customer to fine-tune this
dangerous permission. The user manuals also make this point. I think we
need to underscore this issue in a release note.
Thanks,
-Rick
>
> Note that if derby.system.home is not set the network server sets it
> to user.dir.
>
> Dan.
