zfs discuss - Aug 2006 - ZFS/UFS/TMPFS and extended attributes inconsistent behaviour

As part of looking into a minor issue with the group listed when using 
runat(1) on a UFS filesystem for Johannes (my Google Summer of Code 
student work on new basic file privs), I discovered an even bigger issue 
with UFS and extended attributes.

I''ve cc''d ZFS discuss because I used ZFS as the comparison and
I believe
that ZFS is acting correctly but even then it might not be exactly what 
is expected by some users.

The problem on UFS appears to be related to failed attempts to create
attributes when the file isn''t owned by that user, and then after a 
chown of the file to that user it still fails (even after an umount and 
remount of the filesystem).

For example:

islay:pts/4$ pwd
/var/tmp/testdir
islay:pts/4$ id -a
uid=35661(darrenm) gid=10(staff) groups=10(staff)
islay:pts/4$ ls -ld .
drwxr-xr-x   2 darrenm  staff        512 Aug  7 15:33 ./
islay:pts/4$ touch test1
islay:pts/4$ ls -l /tmp/attrdata
-rw-r--r--   1 darrenm  staff          5 Aug  7 14:50 /tmp/attrdata
islay:pts/4$ runat test1 cp /tmp/attrdata attr.1
islay:pts/4$ runat test1 ls -l
total 2
-rw-r--r--   1 darrenm  staff          5 Aug  7 15:34 attr.1

Okay all as expected.  Now lets put a root owned file into that
directory.

islay:pts/4$ ls -l
total 0
-rw-r--r--   1 darrenm  staff          0 Aug  7 15:34 test1
-rw-r--r--   1 root     root           0 Aug  7 15:34 test2
islay:pts/4$ runat test2 cp /tmp/attrdata attr.1
runat[1790]: missing privilege "ALL" (euid = 35661, syscall = 76)
needed
at ufs_iaccess+0xf8
runat: cannot open attribute directory for test2: Permission denied

No surprises there, in another window lets change the owner to
be darrenm with chown(1):

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:34 test2
islay:pts/4$ runat test2 cp /tmp/attrdata attr.1

Okay that worked as expected.

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.

Okay now in another window change the ownership of this world writable
file to darrenm

islay:pts/4$ runat test3 cp /tmp/attrdata attr.1
cp[1802]: missing privilege "ALL" (euid = 35661, syscall = 224) needed
at ufs_iaccess+0xf8
cp: cannot create attr.1: Permission denied
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 darrenm  staff          0 Aug  7 15:35 test3

Hmn very strange.  On UFS this is still failing as if it were a
root owned file.  On ZFS this case works as expected.

The UFS behaviour is clearly a bug, the default ZFS behaviour of not 
allowing the creation of attributes by anyone other than the actual 
owner (at least by default) maybe a little confusing but I''m not too 
bothered about that.

TMPFS has the same behaviour as UFS with respect to the problem around 
when the chown is done.

-- 
Darren J Moffat

> 
> 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.

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.
> Okay now in another window change the ownership of this world writable
> file to darrenm
> 
> islay:pts/4$ runat test3 cp /tmp/attrdata attr.1
> cp[1802]: missing privilege "ALL" (euid = 35661, syscall = 224)
needed
> at ufs_iaccess+0xf8
> cp: cannot create attr.1: Permission denied
> 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 darrenm  staff          0 Aug  7 15:35 test3
> 
> Hmn very strange.  On UFS this is still failing as if it were a
> root owned file.  On ZFS this case works as expected.
> 
> The UFS behaviour is clearly a bug, the default ZFS behaviour of not 
> allowing the creation of attributes by anyone other than the actual 
> owner (at least by default) maybe a little confusing but I''m not
too
> bothered about that.
> 
> TMPFS has the same behaviour as UFS with respect to the problem around 
> when the chown is done.
>

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.
> 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!

-- 
Darren J Moffat

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!
>

Mark Shellenbaum wrote:
> 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> .
Indeed but the fact that you need to use that workaround is pretty 
nasty.  Of course this assumes anyone actually cares about XATTRS and is 
using them for something useful :-)

Thanks Mark.  I''ll file the bug.


-- 
Darren J Moffat