Date: Sat, 23 Mar 2024 16:58:39 +0000 From: bugzilla-noreply@freebsd.org To: bugs@FreeBSD.org Subject: [Bug 277908] Capsicum filesystem extended attribute support is broken Message-ID: <bug-277908-227-KYUlgDYd9P@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-277908-227@https.bugs.freebsd.org/bugzilla/> References: <bug-277908-227@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D277908 Alan Somers <asomers@FreeBSD.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |asomers@FreeBSD.org Status|New |Open --- Comment #2 from Alan Somers <asomers@FreeBSD.org> --- Ahh, so it's ECAPMODE instead of ENOTCAPABLE. I missed that at first. Her= e's what I've learned through some more dtracing: ZFS has two ways to store extended attributes: SA or dir. IIRC, "dir" is intended for large attributes, which this is not. But zfs_getextattr_sa returns ENOENT, so ZFS then tries zfs_getextattr_dir. But that does vn_open_cred, which calls namei. namei is normally used to look up path na= mes. Looking up absolute pathnames is forbidden in capability mode, so namei returns ECAPMODE. What remains to be determined is why namei thinks we're doing an absolute lookup. I tested this on FreeBSD stable/12, which was before the openzfs import, and got the same result. So the bug has probably been there forever. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-277908-227-KYUlgDYd9P>