From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 10 12:58:40 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 07B584BA; Sun, 10 Nov 2013 12:58:40 +0000 (UTC) (envelope-from etnapierala@gmail.com) Received: from mail-ee0-x22d.google.com (mail-ee0-x22d.google.com [IPv6:2a00:1450:4013:c00::22d]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by mx1.freebsd.org (Postfix) with ESMTPS id 6AD452912; Sun, 10 Nov 2013 12:58:39 +0000 (UTC) Received: by mail-ee0-f45.google.com with SMTP id c4so384072eek.4 for ; Sun, 10 Nov 2013 04:58:37 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:mime-version:content-type:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=/foGp47QLegyoImOInki/6yIf+jIASkqdOECKnFx4e8=; b=jd/i7Hm737HVdYeuqGwz5XXwVCYoppZnh0EdS1RGevmLwqkFl1n5eakfkKl5jRwcNM L5WHn+HlmkjjgtF/eJk/YldWHcFCbVjuDWM1lyabiYn8hKBjynACHSOXDOCIYWJOBp9T Ohh14peXpVQ9WZ0fJsw/6vDQtTNaDwRXTZ9rF9HLzsBxhqwLL0iT//QzkdngtbJs5dl3 xzwLBABGOJo1O9QN0HhM6AEiMoPjW8w2T5c9+Pryg8BlhbAZ9UgqfWtOml3F1Q+WtX4C nsB4qVNyUUaJgoZLN0YE0xsfRjkH30EutNwTm+SvkispkAWICBqGtCaAgx/o9MT6bNZd GXLA== X-Received: by 10.14.122.132 with SMTP id t4mr28846112eeh.20.1384088317910; Sun, 10 Nov 2013 04:58:37 -0800 (PST) Received: from [192.168.1.102] (45.81.datacomsa.pl. [195.34.81.45]) by mx.google.com with ESMTPSA id m54sm40760196eex.2.2013.11.10.04.58.36 for (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Sun, 10 Nov 2013 04:58:37 -0800 (PST) Sender: =?UTF-8?Q?Edward_Tomasz_Napiera=C5=82a?= Subject: Re: Are extended attributes data or meta-data? Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-2 From: =?iso-8859-2?Q?Edward_Tomasz_Napiera=B3a?= In-Reply-To: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> Date: Sun, 10 Nov 2013 13:58:34 +0100 Content-Transfer-Encoding: quoted-printable Message-Id: <496C049F-22C8-46CF-8405-FAF4EBCD3BB8@freebsd.org> References: <704471213.12196154.1384036087256.JavaMail.root@uoguelph.ca> To: Rick Macklem X-Mailer: Apple Mail (2.1283) Cc: freebsd-hackers Hackers , Tim Kientzle 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: Sun, 10 Nov 2013 12:58:40 -0000 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 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?