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