Darren J Moffat wrote:
Mark Shellenbaum wrote:
Lets have another root owned file but this time one that is
world writable:
islay:pts/4$ ls -l
total 0
-rw-r--r-- 1 darrenm staff 0 Aug 7 15:34 test1
-rw-r--r-- 1 darrenm root 0 Aug 7 15:35 test2
-rw-rw-rw- 1 root root 0 Aug 7 15:35 test3
islay:pts/4$ runat test3 cp /tmp/attrdata attr.1
cp[1799]: missing privilege "ALL" (euid = 35661, syscall = 224)
needed at ufs_iaccess+0xf8
cp: cannot create attr.1: Permission denied
Hmn, slightly strange since I would have thought that given write
to the file I could write attributes. ZFS is consistent in this
because the default ZFS ACL does not have everyone@ having
write_xattr. Maybe not quite what one would expect.
Whats happening is that when you change the mode or owner of the base
file the mode and owner of the hidden directory aren't changing. With
UFS the mode of the hidden directory is created when the attribute
directory is initially created. When the mode or owner of the base
file is changed the corresponding mode/owner of the hidden attribute
directory are not updated as well.
So it is a UFS and TMPFS bug then since there appears to be no way
to fix this once it has happened. Even if there is a way to fix it
it is really hard to know that you need to do so until after there
is a problem.
It is a UFS and TMPFS bug, but it can be worked around.
# runat <file> chown <whatever> .
Or if you want to change the mode of the hidden directory.
# runat <file> chmod <whatever> .
This is slightly different in ZFS because it actually has real
permissions for xattr's. Also, when the owner/group of the base file
is changed the owner/group of the hidden directory is also updated.
Good, I though ZFS was doing the correct thing!
_______________________________________________
zfs-discuss mailing list
zfs-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/zfs-discuss
