[
https://issues.apache.org/jira/browse/DERBY-5492?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13145326#comment-13145326
]
Dag H. Wanvik edited comment on DERBY-5492 at 11/8/11 11:58 AM:
----------------------------------------------------------------
Uploading a patch which makes two changes:
- Construct a new AclEntry for the owner with all rights, and removed existing
ones (NTFS). This should handle the error seen in Oracle's regressions.
- For Solaris/ZFS and similar file systems which support both Posix file
attributes view and ACLs, don't touch the ACLs but stick to the Posix flags.
For the latter my rationale is as follows: Principle of least surprise: most
users never touch the ACLs but use the more familiar Posix file masks. It
turned out the existing Derby implementation, although protecting the file
adequately, showed a "+" in the ls(1) listing indicating that the settings
could not be directly mapped onto the Posix model. The reason was that we
removed more permissions than the plain read,write, and execute. Since ZFS
internally builds on ACLs, the ls(1) listing would should that Derby had been
tinkering with the non-mappable ACL permissions. I think it is better to stick
to the Posix permissions by default. If people are using ACL functionality they
are likely more than average concerned with security and can run with default
file permissions and take full responsibility of the permissions fo created
filed. Rationale end.
Rerunning regressions of NTFS, Solaris/ZFS and Linux.
was (Author: dagw):
Uploading a patch which makes two changes:
- Construct a new AclEntry for the owner with all rights, and removed existing
ones (NTFS). This should handle the error seen in Oracle's regressions.
- For Solaris/ZFS and similar file systems which support both Posix file
attributes view and ACLs, don't touch the ACLs but stick to the Posix flags.
Rerunning regressions of NTFS, Solaris/ZFS and Linux.
> Restrictive file permissions: permissions removed also for owner on NTFS if
> Acl does not contain explicit entry for owner
> -------------------------------------------------------------------------------------------------------------------------
>
> Key: DERBY-5492
> URL: https://issues.apache.org/jira/browse/DERBY-5492
> Project: Derby
> Issue Type: Bug
> Components: Store
> Affects Versions: 10.9.0.0
> Reporter: Dag H. Wanvik
> Attachments: derby-5492-1.diff, derby-5492-1.stat
>
>
> It turns out that the file owner does not necessarily get an explicit
> AclEntry; this depends on whether the created file has sufficient permissions
> already through, say, a permission for everybody to write. The present logic
> removes all AclEntries except those granted to the file's owner, erroneously
> presuming there would be such an entry always. This led to all AclEntries
> being removed.
> This error is seen in Oracle's nightly regressions for Windows, but did not
> reproduced when running manually on Windows. This was due to different
> default inherited permissions on the directories in which the regression
> tests were run.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
