Date: Sun, 24 Nov 2013 09:23:27 +0000 From: "Robert N. M. Watson" <rwatson@FreeBSD.org> To: =?utf-8?Q?Edward_Tomasz_Napiera=C5=82a?= <trasz@FreeBSD.org> Cc: Freebsd hackers list <freebsd-hackers@freebsd.org>, Richard Yao <ryao@gentoo.org>, Rick Macklem <rmacklem@uoguelph.ca>, Pedro Giffuni <pfg@FreeBSD.org>, Cedric Blancher <cedric.blancher@gmail.com> Subject: Re: O_XATTR support in FreeBSD? Message-ID: <AA677F6B-DFE6-4D94-9E1F-F42C1D07910B@FreeBSD.org> In-Reply-To: <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org> References: <820263347.19772534.1385247218007.JavaMail.root@uoguelph.ca> <987A1DDC-0C8F-4EEF-9504-D28CA7027F56@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 24 Nov 2013, at 01:28, Edward Tomasz Napiera=C5=82a =
<trasz@FreeBSD.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA677F6B-DFE6-4D94-9E1F-F42C1D07910B>