Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 9 Nov 2013 17:28:07 -0500 (EST)
From:      Rick Macklem <rmacklem@uoguelph.ca>
To:        Tim Kientzle <kientzle@freebsd.org>
Cc:        freebsd-hackers Hackers <freebsd-hackers@freebsd.org>, Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= <trasz@freebsd.org>
Subject:   Re: Are extended attributes data or meta-data?
Message-ID:  <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca>
In-Reply-To: <502A2D02-6AB3-42FC-94D8-261A208751ED@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Tim Kientzle wrote:
> 
> On Nov 8, 2013, at 3:45 PM, Peter Jeremy <peter@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.)

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.

rick

> The extattr(2) manpage should probably document that
> the calls fail on non-readable files.
> 
> Tim
> 
> _______________________________________________
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to
> "freebsd-hackers-unsubscribe@freebsd.org"
> 



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?704471213.12196154.1384036087256.JavaMail.root>