we give the right to add folder to user foo.(this user can not delete anything
as a default) After that we give the right create file.And then user foo gains
delete everthing. How come is it possible.
Even though we add another rule like
"0:user:foo:delete_child/delete:deny". Again it does not work . Why
please somebody answer this strange situation.
we need get answer as a result: user can create file, folder but not delete.
this is it.
ps: we tried it on ntfs (windows 2003) and hfs+ (apple macosx) fs type.
thanks
bash-3.00# zpool create tank c0d0s7
bash-3.00# zfs create tank/fs
bash-3.00# cd /tank/fs
bash-3.00# mkdir test
useradd foo
passwd foo
bash-3.00# chmod A+user:foo:add_file/add_subdirectory:allow test
bash-3.00# chmod A+user:foo:delete_child/delete:deny test
bash-3.00# ls -v
total 3
drwxr-xr-x+ 3 root root 4 Aug 18 15:30 test
0:user:foo:delete_child/delete:deny
1:user:foo:add_file/write_data/add_subdirectory/append_data:allow
2:owner@::deny
3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory
/append_data/write_xattr/execute/write_attributes/write_acl
/write_owner:allow
4:group@:add_file/write_data/add_subdirectory/append_data:deny
5:group@:list_directory/read_data/execute:allow
6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr
/write_attributes/write_acl/write_owner:deny
7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes
/read_acl/synchronize:allow
This message posted from opensolaris.org
ethan gunword wrote:> we give the right to add folder to user foo.(this user can not delete anything as a default) After that we give the right create file.And then user foo gains delete everthing. How come is it possible. > Even though we add another rule like "0:user:foo:delete_child/delete:deny". Again it does not work . Why please somebody answer this strange situation. > > we need get answer as a result: user can create file, folder but not delete. this is it. > > ps: we tried it on ntfs (windows 2003) and hfs+ (apple macosx) fs type. > > thanks > > bash-3.00# zpool create tank c0d0s7 > bash-3.00# zfs create tank/fs > > bash-3.00# cd /tank/fs > bash-3.00# mkdir test > > useradd foo > passwd foo > > bash-3.00# chmod A+user:foo:add_file/add_subdirectory:allow test > bash-3.00# chmod A+user:foo:delete_child/delete:deny test > > bash-3.00# ls -v > total 3 > drwxr-xr-x+ 3 root root 4 Aug 18 15:30 test > 0:user:foo:delete_child/delete:deny > 1:user:foo:add_file/write_data/add_subdirectory/append_data:allow > 2:owner@::deny > 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory > /append_data/write_xattr/execute/write_attributes/write_acl > /write_owner:allow > 4:group@:add_file/write_data/add_subdirectory/append_data:deny > 5:group@:list_directory/read_data/execute:allow > 6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr > /write_attributes/write_acl/write_owner:deny > 7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes > /read_acl/synchronize:allow >Delete permissions are kind of complicated. The recommended NFSv4 enforcement for the ability to delete an object is based on the following chart: ------------------------------------------------------- | Parent Dir | Target Object Permissions | | permissions | | ------------------------------------------------------- | | ACL Allows | ACL Denies| Delete | | | Delete | Delete | unspecified| ------------------------------------------------------- | ACL Allows | Permit | Permit | Permit | | DELETE_CHILD | | ------------------------------------------------------- | ACL Denies | Permit | Deny | Deny | | DELETE_CHILD | | | | ------------------------------------------------------- | ACL specifies | | | | | only allow | Permit | Permit | Permit | | write and | | | | | execute | | | | ------------------------------------------------------- | ACL denies | | | | | write and | Permit | Deny | Deny | | execute | | | | ------------------------------------------------------- This should mean that you are denied delete permission based on row two of the chart. Unfortunately, the code proceeds on and then finds write/execute on the directory. You picked up write when you added add_file to the ACL. Once we find write/execute on the directory we are then on row 3 and access is granted. I have opened bug 6461609 to address this problem. thanks for finding the problem. -Mark
> we give the right to add folder to user foo.(this > user can not delete anything as a default) After that > we give the right create file.And then user foo gains > delete everthing. How come is it possible. > Even though we add another rule like > "0:user:foo:delete_child/delete:deny". Again it does > not work . Why please somebody answer this strange > situation.I can''t find any response to this query from last August. I can confirm that on a Solaris 10 U3 fully patched server that the ''delete_child'' ACL is being ignored in ZFS. Deletion is only controlled by the ''add_file'' ACL. I''m fairly certain that this is in violation of the NFSv4 spec, which zfs claims to implement. The "sticky bit" on a directory is also not reflected in the ACLs output by ''ls -dv'', although it appears to work as usual. I have a nasty suspicion that this is related. -- Carson This message posted from opensolaris.org
Mark Shellenbaum
2007-Apr-03 14:22 UTC
[zfs-discuss] Re: delete acl not working on zfs.v3?
Carson Gaspar wrote:>> we give the right to add folder to user foo.(this >> user can not delete anything as a default) After that >> we give the right create file.And then user foo gains >> delete everthing. How come is it possible. >> Even though we add another rule like >> "0:user:foo:delete_child/delete:deny". Again it does >> not work . Why please somebody answer this strange >> situation. > > I can''t find any response to this query from last August. I can confirm that on a Solaris 10 U3 fully patched server that the ''delete_child'' ACL is being ignored in ZFS. Deletion is only controlled by the ''add_file'' ACL. I''m fairly certain that this is in violation of the NFSv4 spec, which zfs claims to implement. > > The "sticky bit" on a directory is also not reflected in the ACLs output by ''ls -dv'', although it appears to work as usual. I have a nasty suspicion that this is related. >Can you post the full ACL on the directory and on the file you are being allowed to delete. -Mark
Mark Shellenbaum
2007-Apr-03 14:30 UTC
[zfs-discuss] Re: delete acl not working on zfs.v3?
Carson Gaspar wrote:>> we give the right to add folder to user foo.(this >> user can not delete anything as a default) After that >> we give the right create file.And then user foo gains >> delete everthing. How come is it possible. >> Even though we add another rule like >> "0:user:foo:delete_child/delete:deny". Again it does >> not work . Why please somebody answer this strange >> situation. > > I can''t find any response to this query from last August. I can confirm that on a Solaris 10 U3 fully patched server that the ''delete_child'' ACL is being ignored in ZFS. Deletion is only controlled by the ''add_file'' ACL. I''m fairly certain that this is in violation of the NFSv4 spec, which zfs claims to implement. > > The "sticky bit" on a directory is also not reflected in the ACLs output by ''ls -dv'', although it appears to work as usual. I have a nasty suspicion that this is related. >I would suspect you are seeing: 6541829 zfs delete permissions are not working correctly. That bug is fixed in Nevada, and will be in update 4. -Mark
Mark Shellenbaum wrote:> Can you post the full ACL on the directory and on the file you are being > allowed to delete.Simple test: carson:gandalf 2 $ uname -a SunOS gandalf.taltos.org 5.10 Generic_125101-02 i86pc i386 i86pc carson:gandalf 0 $ mkdir foo carson:gandalf 0 $ ls -dv foo drwxr-xr-x 2 carson carson 2 Apr 3 07:28 foo 0:owner@::deny 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 2:group@:add_file/write_data/add_subdirectory/append_data:deny 3:group@:list_directory/read_data/execute:allow 4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr /write_attributes/write_acl/write_owner:deny 5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow carson:gandalf 0 $ chmod A+everyone@:add_file:allow foo carson:gandalf 0 $ chmod A+everyone@:delete_child:deny foo Tue Apr 03 07:30:41 /export/data/acltest carson:gandalf 0 $ ls -dv foo drwxrwxrwx+ 2 carson carson 2 Apr 3 07:30 foo 0:everyone@:delete_child:deny 1:everyone@:add_file/write_data:allow 2:owner@::deny 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 4:group@:add_file/write_data/add_subdirectory/append_data:deny 5:group@:list_directory/read_data/execute:allow 6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr /write_attributes/write_acl/write_owner:deny 7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow carson:gandalf 0 $ touch foo/bar carson:gandalf 0 $ ls -v foo/bar -rw-r--r-- 1 carson carson 0 Apr 3 07:29 foo/bar 0:owner@:execute:deny 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 2:group@:write_data/append_data/execute:deny 3:group@:read_data:allow 4:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow (different user) gabe:gandalf 0 $ rm foo/bar rm: foo/bar: override protection 644 (yes/no)? yes carson:gandalf 0 $ ls -v foo/bar foo/bar: No such file or directory Let''s make it more fun: carson:gandalf 0 $ touch foo/bar carson:gandalf 0 $ chmod A+everyone@:delete:deny foo/bar carson:gandalf 0 $ ls -dv foo/bar -rw-r--r--+ 1 carson carson 0 Apr 3 07:33 foo/bar 0:everyone@:delete:deny 1:owner@:execute:deny 2:owner@:read_data/write_data/append_data/write_xattr/write_attributes /write_acl/write_owner:allow 3:group@:write_data/append_data/execute:deny 4:group@:read_data:allow 5:everyone@:write_data/append_data/write_xattr/execute/write_attributes /write_acl/write_owner:deny 6:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize :allow gabe:gandalf 0 $ rm foo/bar rm: foo/bar: override protection 644 (yes/no)? yes carson:gandalf 0 $ ls -dv foo/bar foo/bar: No such file or directory -- Carson
Mark Shellenbaum
2007-Apr-03 14:47 UTC
[zfs-discuss] Re: delete acl not working on zfs.v3?
Carson Gaspar wrote:> Mark Shellenbaum wrote: > >> Can you post the full ACL on the directory and on the file you are >> being allowed to delete. > > Simple test: > > carson:gandalf 2 $ uname -a > SunOS gandalf.taltos.org 5.10 Generic_125101-02 i86pc i386 i86pc > > carson:gandalf 0 $ mkdir foo > > carson:gandalf 0 $ ls -dv foo > drwxr-xr-x 2 carson carson 2 Apr 3 07:28 foo > 0:owner@::deny > 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory > /append_data/write_xattr/execute/write_attributes/write_acl > /write_owner:allow > 2:group@:add_file/write_data/add_subdirectory/append_data:deny > 3:group@:list_directory/read_data/execute:allow > > 4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr > /write_attributes/write_acl/write_owner:deny > > 5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes > /read_acl/synchronize:allow > > carson:gandalf 0 $ chmod A+everyone@:add_file:allow foo > > carson:gandalf 0 $ chmod A+everyone@:delete_child:deny foo > > Tue Apr 03 07:30:41 /export/data/acltest > carson:gandalf 0 $ ls -dv foo > drwxrwxrwx+ 2 carson carson 2 Apr 3 07:30 foo > 0:everyone@:delete_child:deny > 1:everyone@:add_file/write_data:allow > 2:owner@::deny > 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory > /append_data/write_xattr/execute/write_attributes/write_acl > /write_owner:allow > 4:group@:add_file/write_data/add_subdirectory/append_data:deny > 5:group@:list_directory/read_data/execute:allow > > 6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr > /write_attributes/write_acl/write_owner:deny > > 7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes > /read_acl/synchronize:allow > > carson:gandalf 0 $ touch foo/bar > > carson:gandalf 0 $ ls -v foo/bar > -rw-r--r-- 1 carson carson 0 Apr 3 07:29 foo/bar > 0:owner@:execute:deny > 1:owner@:read_data/write_data/append_data/write_xattr/write_attributes > /write_acl/write_owner:allow > 2:group@:write_data/append_data/execute:deny > 3:group@:read_data:allow > > 4:everyone@:write_data/append_data/write_xattr/execute/write_attributes > /write_acl/write_owner:deny > 5:everyone@:read_data/read_xattr/read_attributes/read_acl/synchronize > :allow > > (different user) > > gabe:gandalf 0 $ rm foo/bar > rm: foo/bar: override protection 644 (yes/no)? yes > > carson:gandalf 0 $ ls -v foo/bar > foo/bar: No such file or directory >This appears to work correctly in Nevada. $ cd /sandbox $ mkdir foo $ ls -dv foo drwxr-xr-x 2 marks staff 2 Apr 3 08:42 foo 0:owner@::deny 1:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 2:group@:add_file/write_data/add_subdirectory/append_data:deny 3:group@:list_directory/read_data/execute:allow 4:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr /write_attributes/write_acl/write_owner:deny 5:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow $ chmod A+everyone@:delete_child:deny foo $ ls -dv foo drwxrwxrwx+ 2 marks staff 2 Apr 3 08:42 foo 0:everyone@:delete_child:deny 1:everyone@:add_file/write_data:allow 2:owner@::deny 3:owner@:list_directory/read_data/add_file/write_data/add_subdirectory /append_data/write_xattr/execute/write_attributes/write_acl /write_owner:allow 4:group@:add_file/write_data/add_subdirectory/append_data:deny 5:group@:list_directory/read_data/execute:allow 6:everyone@:add_file/write_data/add_subdirectory/append_data/write_xattr /write_attributes/write_acl/write_owner:deny 7:everyone@:list_directory/read_data/read_xattr/execute/read_attributes /read_acl/synchronize:allow $ touch foo/bar Switch to user "lp" lp$ rm foo/bar rm: foo/bar: override protection 644 (yes/no)? y rm: foo/bar not removed: Permission denied lp$ ls foo test lp$ ls foo/bar foo/bar