From owner-freebsd-hackers@FreeBSD.ORG Sun Nov 24 09:23:39 2013 Return-Path: Delivered-To: freebsd-hackers@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1A5209F3; Sun, 24 Nov 2013 09:23:39 +0000 (UTC) Received: from cyrus.watson.org (cyrus.watson.org [198.74.231.69]) by mx1.freebsd.org (Postfix) with ESMTP id CACA0282C; Sun, 24 Nov 2013 09:23:38 +0000 (UTC) Received: from [10.0.1.16] (host86-132-106-161.range86-132.btcentralplus.com [86.132.106.161]) by cyrus.watson.org (Postfix) with ESMTPSA id 830EB46B2A; Sun, 24 Nov 2013 04:23:35 -0500 (EST) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 7.0 \(1822\)) Subject: Re: O_XATTR support in FreeBSD? From: "Robert N. M. Watson" In-Reply-To: <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> Date: Sun, 24 Nov 2013 09:23:27 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= X-Mailer: Apple Mail (2.1822) Cc: Freebsd hackers list , Richard Yao , Rick Macklem , Pedro Giffuni , Cedric Blancher X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.16 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 24 Nov 2013 09:23:39 -0000 On 24 Nov 2013, at 01:28, Edward Tomasz Napiera=C5=82a = wrote: >>> I was unaware of a standard for EA beyond the old posix draft. >>> The reason for Extended Attributes is supporting ACL and we support >>> both >>> the draft posix and the NFS/win style ACLs. >>>=20 >> Interestingly, FreeBSD has a VOP_OPENEXTATTR() but no syscall >> that uses it nor support for it in ZFS. (I'm just guessing it >> was intended for an openat(2) syscall at some time?) >=20 > Hm, interesting. It looks kind of unused (MAC uses it to implement > mac_vnode_create_extattr() and mac_vnode_setlabel_extattr()). Robert = (Cc-ed), > perhaps you know what=E2=80=99s the story here? >=20 > % grep -R openextattr * =20 > fs/unionfs/union.h:#define UNIONFS_OPENEXTL 0x01 /* openextattr = (lower) */ > fs/unionfs/union.h:#define UNIONFS_OPENEXTU 0x02 /* openextattr = (upper) */ > fs/unionfs/union_vnops.c:unionfs_openextattr(struct = vop_openextattr_args *ap) > fs/unionfs/union_vnops.c: .vop_openextattr =3D = unionfs_openextattr, > kern/vnode_if.src:%% openextattr vp L L L > kern/vnode_if.src:vop_openextattr { > ufs/ffs/ffs_vnops.c:static vop_openextattr_t ffs_openextattr; > ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, > ufs/ffs/ffs_vnops.c: .vop_openextattr =3D ffs_openextattr, > ufs/ffs/ffs_vnops.c:ffs_openextattr(struct vop_openextattr_args *ap) > ufs/ffs/ffs_vnops.c:struct vop_openextattr_args { >=20 > % grep -R VOP_OPENEXTATTR * > fs/unionfs/union_vnops.c: error =3D VOP_OPENEXTATTR(tvp, = ap->a_cred, ap->a_td); > fs/unionfs/union_vnops.c: = VOP_OPENEXTATTR(lvp, cred, td)) { > fs/unionfs/union_vnops.c: = panic("unionfs: VOP_OPENEXTATTR failed"); > fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) > fs/unionfs/union_vnops.c: = VOP_OPENEXTATTR(lvp, cred, td)) { > fs/unionfs/union_vnops.c: = panic("unionfs: VOP_OPENEXTATTR failed"); > fs/unionfs/union_vnops.c: if ((error =3D = VOP_OPENEXTATTR(uvp, cred, td)) !=3D 0) > security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, = curthread); > security/mac/mac_vfs.c: error =3D VOP_OPENEXTATTR(vp, cred, = curthread); >=20 > Anyway - extended attributes _are_ supported on ZFS; see extattr(2) = for API. This VOP doesn't do what you think it does. Within our VFS we support = "transactions" in order to allow multiple EA writes to be atomic. This = is used when setting labels associated with multiple policies in a = single call to mac_set_file(), mac_set_fd(), and mac_set_link(). This = provides atomicity against (a) simultaneous access to the same file as = security attributes are changing, and (b) in the event of a crash during = attribute update. The transaction model depends on the vnode lock being = held exclusively over the call to VOP_OPENEXTATTR(), a series of = VOP_SETEXTATTR() calls, and VOP_CLOSEEXTATTR(). The feature was added in = UFS2 (it's not present in the UFS1 EA implementation), and it looks like = extattr(9) didn't get updated. Robert