From owner-freebsd-hackers@FreeBSD.ORG Sat Nov 9 22:29:16 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id AEAC213D; Sat, 9 Nov 2013 22:29:16 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from esa-jnhn.mail.uoguelph.ca (esa-jnhn.mail.uoguelph.ca [131.104.91.44]) by mx1.freebsd.org (Postfix) with ESMTP id 4F8D02694; Sat, 9 Nov 2013 22:29:16 +0000 (UTC) X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AqQEABW2flKDaFve/2dsb2JhbABZgz9TgnS7W0qBPnSCJQEBAQMBAQEBIAQnIAsFFhgCAg0ZAikBCSYGCAcEARwEh1oGDapEkhuBKY0FgQU0B4JrgUUDiUKLfoN+kFuDRB4xgQQ5 X-IronPort-AV: E=Sophos;i="4.93,669,1378872000"; d="scan'208";a="68484756" Received: from muskoka.cs.uoguelph.ca (HELO zcs3.mail.uoguelph.ca) ([131.104.91.222]) by esa-jnhn.mail.uoguelph.ca with ESMTP; 09 Nov 2013 17:28:07 -0500 Received: from zcs3.mail.uoguelph.ca (localhost.localdomain [127.0.0.1]) by zcs3.mail.uoguelph.ca (Postfix) with ESMTP id 417FAB402B; Sat, 9 Nov 2013 17:28:07 -0500 (EST) Date: Sat, 9 Nov 2013 17:28:07 -0500 (EST) From: Rick Macklem To: Tim Kientzle Message-ID: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> In-Reply-To: <502A2D02-6AB3-42FC-94D8-261A208751ED@freebsd.org> Subject: Re: Are extended attributes data or meta-data? MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [172.17.91.201] X-Mailer: Zimbra 7.2.1_GA_2790 (ZimbraWebClient - FF3.0 (Win)/7.2.1_GA_2790) Cc: freebsd-hackers Hackers , Edward Tomasz =?utf-8?Q?Napiera=C5=82a?= X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 09 Nov 2013 22:29:16 -0000 Tim Kientzle wrote: > > On Nov 8, 2013, at 3:45 PM, Peter Jeremy 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" >