Are extended attributes data or meta-data?

Edward Tomasz Napierała trasz at freebsd.org
Sun Nov 10 12:58:40 UTC 2013


Wiadomość napisana przez Rick Macklem w dniu 9 lis 2013, o godz. 23:28:
> Tim Kientzle wrote:
>> 
>> On Nov 8, 2013, at 3:45 PM, Peter Jeremy <peter at rulingia.com> wrote:
>> 
>>> I've been getting regular error messages logged by afpd:
>>> Nov  9 00:00:19 server afpd[1966]: sys_getextattr_size: error:
>>> Permission denied
>>> I have spent some time digging into it and it's triggered by
>>> extattr_get_link(2) returning EACCESS because a file is not
>>> readable,
>>> but stat(2) on the file succeeded.
>>> 
>>> According to extattr(2), "[n]amed extended attributes are meta-data
>>> associated with vnodes" but the actual code for VOP_GETEXTATTR()
>>> (at least
>>> for ufs & zfs) checks for VREAD access, whereas the VOP_GETATTR()
>>> call
>>> (used by stat(2)) doesn't include any access checks (so stat(2)
>>> will
>>> succeed unless namei() fails).
>>> 
>>> IMHO, this behaviour is inconsistent:  The extended attributes are
>>> documented as "meta-data" and but the access checks are for "data".
>>> Which is correct?
>> 
>> Practically speaking, extended attributes are used both
>> for data and metadata.
>> 
>> I would consider the existing behavior (extattr calls fail on
>> non-readable files) to be correct in the absence of NFSv4
>> ACLs (which include a specific permission for extattr readability).
>> 
> Actually, NFSv4 doesn't support the notion of extended attributes at
> this time. It is being discussed for a future minor version. It does
> support the notion of fork files/subfiles, but I think they get their own
> ACLs.
> 
> I believe the Read_attribute and Write_attribute flags in NFSv4 ACLs
> refer to the regular attributes and not extended ones. (I've cc'd trasz,
> since he'll know.)

Exactly - the read_attributes/write_attributes NFSv4 ACL permissions
are for the "normal" file attributes, such as access/change/modify times.
The read_xattr/write_xattr permissions are ignored; access to extended
attributes requires the same permissions as for the file contents.

> The Fedoro/Linux "man attr" states that extended attributes in their "user"
> name space are access controlled via the normal file mechanisms, so I
> believe Linux does check for read/write permissions. Since Linux distros
> are the lion's (not referring to an OS X version;-) share of what's out
> there, I'd say their semantics are defacto standard.
> --> I think that checking for read (or write) access for extended attributes
>    is correct.

Just for the record, on SunOS access to alternate data streams in ZFS
(which we use to store extended attributes) doesn't use the read_xattr
and write_xattr permisions either.

-- 
If you cut off my head, what would I say?  Me and my head, or me and my body?



More information about the freebsd-hackers mailing list