[
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)
