Dag H. Wanvik wrote:
Prevent export from overwriting existing files
----------------------------------------------
Key: DERBY-2925
URL: https://issues.apache.org/jira/browse/DERBY-2925
Project: Derby
Issue Type: Sub-task
Components: Security, Tools
Affects Versions: 10.1.2.1, 10.2.2.0, 10.3.1.3, 10.4.0.0
Reporter: Kathey Marsden
Assignee: Ramin Moazeni
Export should not overwrite existing files, but rather insist that
the user remove them before writing to the file. This will help
prevent accidental or intentional corruption of the database with
export. This may introduce a compatibility issue with export but
because export is usually an attended utility and not typically
invoked as part of an application, I think the risk is worth the
additional security this will provide.
I am not sure blanket prohibition on exporting to existing files is
the best approach. Apart from the compatibility issue I would say
there is a usability issue as well, I know I never use "noclobber" in
my UNIX shell settings ;) I think what we are trying to achieve here
is to protect the database files. Couldn't a separate jar for this
part of the code solve the issue (with a policy only allowing write to
a dedicated export directory by default). If a separate jar is
considered undesirable, one could limit the export to a relative file
path and always require that it contain an export directory as its
first path element, say "export". Just my 0.02 cents, please forgive
if I missed some context discussions here.
I don't think adding another jar will improve usability. I think the
restriction of a dedicated export directory or restrictions on directory
names for export will also not improve usability. I think it is
reasonable to expect the user to delete pre-existing files before
exporting over them. But this is all just a straight difference of opinion.
Kathey