On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote:
> I have written a short test program that runs unlinkat(2) in
> capability mode and fails due to not having the write capabilities:
>
> https://people.freebsd.org/~rstone/src/unlink.c
>
> If I run the binary under ktrace and look at the kdump output, it
> gives the following incorrect output:
>
> 43775 unlink CALL unlinkat(0x3,0x7fffffffe995,0)
> 43775 unlink NAMI "from.QAUlAA0"
> 43775 unlink CAP operation requires CAP_LOOKUP, descriptor holds
> CAP_LOOKUP
> 43775 unlink RET unlinkat -1 errno 93 Capabilities insufficient
>
> The message should instead say that the operation requires
> CAP_UNLINKAT. Looking at sys/capsicum.h, I suspect that the problem
> is related to the strange definition of CAP_UNLINKAT:
>
> #define CAP_UNLINKAT (CAP_LOOKUP | 0x0000000010000000ULL)
FYI, with this grep it was able to decode capabilities.
Index: lib/libsysdecode/mktables
===================================================================
--- lib/libsysdecode/mktables (revision 352685)
+++ lib/libsysdecode/mktables (working copy)
@@ -157,7 +157,7 @@
gen_table "sigcode" "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"
"sys/signal.h"
gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"
"sys/umtx.h"
gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"
"sys/umtx.h"
-gen_table "caprights"
"CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"
"sys/capsicum.h"
+gen_table "caprights"
"CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"
"sys/capsicum.h"
gen_table "sctpprpolicy" "SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+"
"netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
gen_table "cmsgtypesocket" "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"
"sys/socket.h"
if [ -e "${include_dir}/x86/sysarch.h" ]; then
On unlink.c, it gives:
45494 unlink CALL cap_rights_limit(0x3,0x7fffffffead0)
45494 unlink STRU cap_rights_t CAP_LOOKUP
45494 unlink RET cap_rights_limit 0
45494 unlink CALL openat(AT_FDCWD,0x200323,0<O_RDONLY>)
45494 unlink NAMI "/tmp"
45494 unlink RET openat 4
45494 unlink CALL cap_rights_limit(0x4,0x7fffffffead0)
45494 unlink STRU cap_rights_t CAP_LOOKUP,CAP_UNLINKAT
45494 unlink RET cap_rights_limit 0
45494 unlink CALL cap_enter
45494 unlink RET cap_enter 0
45494 unlink CALL unlinkat(0x3,0x7fffffffeaa5,0)
45494 unlink NAMI "from.YG6jQx2"
45494 unlink CAP operation requires CAP_LOOKUP,CAP_UNLINKAT, descriptor
holds CAP_LOOKUP
> I have observed the same problem with renameat(2) and
> CAP_RENAMEAT_SOURCE and CAP_RENAMEAT_TARGET:
>
> https://people.freebsd.org/~rstone/src/rename.c
49410 rename CAP operation requires CAP_LOOKUP,CAP_RENAMEAT_SOURCE,
descriptor holds CAP_LOOKUP
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
