Mailing-List: contact derby-dev-help@db.apache.org; run by ezmlm
Precedence: bulk
Reply-To: <derby-dev@db.apache.org>
Date: Tue, 9 Sep 2014 10:50:29 +0000 (UTC)
From: "Knut Anders Hatlen (JIRA)" <jira@apache.org>
To: derby-dev@db.apache.org
Message-ID: <JIRA.12702580.1395304560000.26861.1410259829140@Atlassian.JIRA>
In-Reply-To: <JIRA.12702580.1395304560000@Atlassian.JIRA>
References: <JIRA.12702580.1395304560000@Atlassian.JIRA>
 <JIRA.12702580.1395304560165@arcas>
Subject: [jira] [Commented] (DERBY-6521) Improve error handling when
 restricting file permissions
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


    [ https://issues.apache.org/jira/browse/DERBY-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14126860#comment-14126860 ] 

Knut Anders Hatlen commented on DERBY-6521:
-------------------------------------------

The exception will be raised. This was already the behaviour when running on Windows. The change made in this issue was to make non-Windows platforms behave the same way. So the applications that might see a new exception now are those that start the network server from the command line on Java 7 or higher on a non-Windows platform where the underlying file system supports changing file permissions.

I guess a release note could have been added for this change. Unfortunately, it's too late to get it into the 10.11.1.1 release notes now.

In 10.9 and 10.10, there were asserts that would have raised exceptions if the permissions could not be changed in those configurations. We never saw those asserts fail in any of the platform tests, as far as I can recall. Hopefully, that's a good indication that this change isn't going to be noticed by many users.

As to running RestrictiveFilePermissionsTest under Java 6, Dag said the following in a comment on DERBY-5363 when the test was added:

{quote}
Footnote: the reason why we can *restrict* but not test permission with Java 6 is that this would require running a test with another OS user; there is no way to inspect the permissions, only to restrict them, essentially. Cf File.setWriteable & friends.
{quote}

> Improve error handling when restricting file permissions
> --------------------------------------------------------
>
>                 Key: DERBY-6521
>                 URL: https://issues.apache.org/jira/browse/DERBY-6521
>             Project: Derby
>          Issue Type: Improvement
>          Components: Services
>    Affects Versions: 10.11.1.1
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>             Fix For: 10.11.1.1
>
>         Attachments: d6521-1a.diff, d6521-1b.diff
>
>
> In DERBY-6503 there was some discussion about changing how errors are handled when Derby fails to restrict the file permissions.
> There seemed to be consensus that Derby should raise an exception if the user had explicitly requested (by setting derby.storage.useDefaultFilePermissions=false) that it should try to restrict file permissions. Currently, it only raises an error on non-posix file systems that support access control lists.
> In the case were the user has not explicitly requested restriction of file permissions, two options have been suggested:
> 1) Raise an exception
> 2) Don't raise an exception, possibly print a warning in derby.log
> Option 1 is the more secure one, since it forces the user to make a decision on how to handle a possible security problem (either by addressing the underlying cause of the failure, so that permissions can be successfully restricted by Derby, or by disabling the file restriction functionality).
> Option 2 is the more backward compatible one, since it gracefully falls back to the pre-10.10/pre-Java 7 behaviour if it cannot restrict the file permissions.


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)