Date: Sun, 10 Nov 2013 13:58:34 +0100 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= <trasz@freebsd.org> To: Rick Macklem <rmacklem@uoguelph.ca> Cc: freebsd-hackers Hackers <freebsd-hackers@freebsd.org>, Tim Kientzle <kientzle@freebsd.org> Subject: Re: Are extended attributes data or meta-data? Message-ID: <496C049F-22C8-46CF-8405-FAF4EBCD3BB8@freebsd.org> In-Reply-To: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> References: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca>
next in thread | previous in thread | raw e-mail | index | archive | help
Wiadomo=B6=E6 napisana przez Rick Macklem w dniu 9 lis 2013, o godz. = 23:28: > Tim Kientzle wrote: >>=20 >> On Nov 8, 2013, at 3:45 PM, Peter Jeremy <peter@rulingia.com> wrote: >>=20 >>> 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. >>>=20 >>> 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). >>>=20 >>> IMHO, this behaviour is inconsistent: The extended attributes are >>> documented as "meta-data" and but the access checks are for "data". >>> Which is correct? >>=20 >> Practically speaking, extended attributes are used both >> for data and metadata. >>=20 >> 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). >>=20 > 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. >=20 > 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. --=20 If you cut off my head, what would I say? Me and my head, or me and my = body?
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?496C049F-22C8-46CF-8405-FAF4EBCD3BB8>