Project

General

Profile

Bug #3528

setting permission with chmod kills delete_child permission on owner acl

Added by Klaus Steinberger about 7 years ago. Updated over 3 years ago.

Status:
Closed
Priority:
High
Assignee:
-
Category:
-
Start date:
2013-02-05
Due date:
% Done:

50%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage

Description

Hi,

we do have the following problem:

when a directory has the delete_child permission, after changing mode bits the delete_child right has gone!

See this dialog:

root@gar-sv-oi02:/gar-home/home/w# ls -vd zz
drwx------+  2 root     root           2 Feb  5 11:49 zz
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/delete/read_acl/write_acl
         /write_owner/synchronize:dir_inherit/inherited:allow
     1:everyone@:read_attributes/synchronize:inherited:allow
root@gar-sv-oi02:/gar-home/home/w# 
root@gar-sv-oi02:/gar-home/home/w# 
root@gar-sv-oi02:/gar-home/home/w# chmod g+rx zz
root@gar-sv-oi02:/gar-home/home/w# ls -vd zz
drwxr-x---   2 root     root           2 Feb  5 11:49 zz
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow
root@gar-sv-oi02:/gar-home/home/w# chmod A0=owner@:full_set/synchronize:allow zz
root@gar-sv-oi02:/gar-home/home/w# ls -vd zz
drwxr-x---+  2 root     root           2 Feb  5 11:49 zz
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/delete_child
         /read_attributes/write_attributes/delete/read_acl/write_acl
         /write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:read_xattr/read_attributes/read_acl/synchronize:allow
root@gar-sv-oi02:/gar-home/home/w# chmod o+rx zz
root@gar-sv-oi02:/gar-home/home/w# ls -vd zz
drwxr-xr-x   2 root     root           2 Feb  5 11:49 zz
     0:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
         /append_data/read_xattr/write_xattr/execute/read_attributes
         /write_attributes/read_acl/write_acl/write_owner/synchronize:allow
     1:group@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
     2:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
         /read_acl/synchronize:allow
root@gar-sv-oi02:/gar-home/home/w# 

root@gar-sv-oi02:/gar-home/home/w# zfs get all gar-home/home | grep aclgar-home/home  aclmode               passthrough                                                 local
gar-home/home  aclinherit            passthrough-x                                               local
root@gar-sv-oi02:/gar-home/home/w# 
root@gar-sv-oi02:/gar-home/home/w# cat /etc/*rel*
             OpenIndiana Development oi_151.1.7 X86 (powered by illumos)
        Copyright 2011 Oracle and/or its affiliates. All rights reserved.
                        Use is subject to license terms.
                           Assembled 03 October 2012
root@gar-sv-oi02:/gar-home/home/w#

We already tried also aclmode=discard and aclinherit=restricted, but to no help.

the missing delete_child permission creates trouble for our windows users, they can not move or delete files.

On a nexenta box this does not happen!

Related issues

Related to illumos gate - Bug #807: Trivial ACEs missing deleteClosed2011-03-12

Actions
Is duplicate of illumos gate - Bug #6762: POSIX write should imply DELETE_CHILD on directories - and some additional considerationsClosed2016-03-19

Actions

History

#1

Updated by Gordon Ross about 7 years ago

This should be an illumos bug, btw. (I don't have the rights needed to fix that.)

We fixed this in NexentaStor, and had a fix out for review at one point.
I'll try to get someone at Nexenta to resurrect that...

#2

Updated by Rich Lowe about 7 years ago

  • Project changed from OpenIndiana Distribution to illumos gate
#3

Updated by Gordon Ross about 7 years ago

  • Assignee set to Gordon Ross

OK, I found the workspace where I left this fix parked.

The problem here, btw, is that Windows really expects the DELETE bit to be there
for a "normal" directory where you also have DELETE_CHILD, etc. Unfortunately,
the handling of that bit, and it's interaction with other permission checks
(and in particular the POSIX "sticky" bit) get's rather complicated.

#4

Updated by Gordon Ross almost 7 years ago

  • Assignee changed from Gordon Ross to Kevin Crowe
  • % Done changed from 0 to 50
#5

Updated by Gordon Ross almost 7 years ago

  • Status changed from New to In Progress
#6

Updated by Klaus Steinberger over 6 years ago

Hi Gordon,

what's the status of this bug? Any progress?

Sincerly,
Klaus

#7

Updated by Kevin Crowe over 6 years ago

Just a quick update on progress: I took this bug from Gordon & I have some code changes I'd consider just about ready. There was one finding on an internal code review that I need to address and I hope to move forward in the next week or two retesting and following up on that code review and seeking community feedback.

#8

Updated by Joshua M. Clulow over 3 years ago

  • Assignee deleted (Kevin Crowe)
#9

Updated by Yuri Pankov over 3 years ago

  • Status changed from In Progress to Feedback

This should be fixed in #6762.

#10

Updated by Yuri Pankov over 3 years ago

  • Status changed from Feedback to Closed

Closing as fixed, please reopen if it's still a problem.

#11

Updated by Yuri Pankov over 3 years ago

  • Is duplicate of Bug #6762: POSIX write should imply DELETE_CHILD on directories - and some additional considerations added

Also available in: Atom PDF