[jira] [Updated] (DERBY-6521) Improve error handling when restricting file permissions

["Knut Anders Hatlen (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/DERBY-6521?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Knut Anders Hatlen updated DERBY-6521:
--------------------------------------

    Attachment: d6521-1a.diff

Attaching a patch, d6521-1a.diff, which shows one possible and not so complex solution.

The approach has the following characteristics:

* There is no difference between the case where restrictive file permissions are enabled by default and the case where they are explicitly enabled by the user.

* When running on Java 7, and the file system supports restricting file permissions, and something goes wrong, fail and report the IOException.

* If we fall back to the Java 6 mechanism for restricting file permissions (either because we are in fact running on Java 6, or because the file system doesn't have the concept of a file owner) and something goes wrong, don't raise an error.

The reasons why I'm leaning towards this approach are mainly of pragmatic nature:

* Having the same behaviour in the default case and the explicitly enabled case is
** Easier to explain.
** Easier to code. The alternative (writing a warning in derby.log instead of failing in the default case) is problematic both because FileUtil.limitAccessToOwner() is used outside of the engine, and because these problems, if they occur, are very likely to pop up early before derby.system.home and derby.log have been created, so there's no derby.log to write to. (Both DERBY-6410 and DERBY-6503 were seen when attempting to create derby.log.)

* Reporting the IOExceptions thrown by the Java 7 FileAttributeViews sounds reasonable to do, also in the default case, since we only use the FileAttributeViews on file systems where we expect it to be possible to change the permissions, and we get an IOException that explains the root cause, so there's a good chance the user can fix the problem.

* When the Java 6 mechanism is used, we only get a true/false response from the system, so it's difficult to give a good error message. I'm not so worried about not reporting these errors on Java 6, since restrictive file permissions is primarily a feature for Java 7 and higher (for example, we only enable it by default on the network server if we are running Java 7 and higher).

* When we are running on a file system that doesn't distinguish between the owner of the file and other users (such as FAT), there's not much that could be done, so regarding it as a successful no-op rather than an unsuccessful operation doesn't sound totally unreasonable. That would allow applications running on such legacy systems to continue working without any workarounds.

The only change in behaviour that results from this patch, is that failures to change permission on POSIX file systems with Java 7 or higher will be reported as errors. The behaviour in all other configurations should be unchanged. So it will be slightly stricter than before, and more consistent between Windows and *nix platforms, but not so strict that it will break compatibility with legacy systems.

All the regression tests passed with the patch. I ran RestrictiveFilePermissionsTest both on Linux and Windows with JDK 6, 7 and 8.

> 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.0.0
>            Reporter: Knut Anders Hatlen
>            Assignee: Knut Anders Hatlen
>         Attachments: d6521-1a.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.2#6252)