Skip site navigation (1)Skip section navigation (2)
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>