In D40676#1027002, @markj wrote:

In D40676#1027000, @gallatin wrote:

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled, which is confusing and distracting. Can this please be reverted to behave without CAP output for systems w/o capsicum ?

This was done already in commit f239db4800ee9e7ff8485f96b7a68e6c38178c3b.

In D40676#1027003, @theraven wrote:

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled

Are systems without Capsicum still supported? I thought that option was removed in 14.

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled

In D40676#1027000, @gallatin wrote:

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled, which is confusing and distracting. Can this please be reverted to behave without CAP output for systems w/o capsicum ?

After this change, ktrace output is littered with 'CAP system call not allowed: $SYSCALL' on systems w/o capsicum enabled, which is confusing and distracting. Can this please be reverted to behave without CAP output for systems w/o capsicum ?

• Record *namei* violations instead of vfs. Slight wording change for clarity.
• Rebase on main after several months

• Rename all instances of CAPFAIL_VFS to CAPFAIL_NAMEI
• Rebase on main after several months

• Address Mark's comments
• Rebase on main after several months

Replace all instances of "AT_FDCWD" with "<AT_FDCWD>" when reporting a violation via ktrcapfail().

In D40677#988214, @markj wrote:

I would frown at that. :) It introduces hidden control flow which makes it hard to see quickly what a function does.

Consider the common case where a function allocates some memory and is supposed to free it before returning: if I'm reviewing the code and want to verify it behaves properly with respect to that free() call, it's much easier to check if I just have to look for the "return" keyword in the function.

Once in a while it's handy, but it should be avoided if possible.

In D40677#988077, @jfree wrote:

Actually, scratch that. I just understood your comment and this is a better solution.

As a side note though... Is returning in macros usually frowned upon?

Actually, scratch that. I just understood your comment and this is a better solution.

It feels wrong to return inside of a macro, but I did not see any comments about it in style(9). This seems to be the solution that is most elegant in minimizing code duplication. Let me know your thoughts.

Hello Jake,

I created this patch to make the Capsicumization experience less intimidating for inexperienced developers. Both David and Mariusz may not be the target audience for this change

I created this patch to make the Capsicumization experience less intimidating for inexperienced developers. Both David and Mariusz may not be the target audience for this change because they already know how to extract the information that the tracing provides. Developers that are unfamiliar with Capsicum's semantics could use this tracing mode to easily determine why their program is not working in capability mode. I think it provides a solid starting point so new developers don't get lost and discouraged.

It's doable in principle, but in practice dtrace's inability to resolve backtraces in the face of fork/exec makes it mostly unusable

In D40676#958341, @theraven wrote:

Are these events exposed to DTrace? When sandboxing, the thing I really want is a stack trace in userspace at the point where the violation happened. If so, it would be great to include a script that logged them. Ideally with an option of an explicit start marker so you can put in a fake cap_enter and be told what you still need to fix.

Are these events exposed to DTrace? When sandboxing, the thing I really want is a stack trace in userspace at the point where the violation happened. If so, it would be great to include a script that logged them. Ideally with an option of an explicit start marker so you can put in a fake cap_enter and be told what you still need to fix.

Ah, ok I thought it was printed by default.
Then I don't think I have any complaints through the idea.

In D40676#958254, @oshogbo wrote:

If I understand correctly, for application like:

localtime();
open();
cap_enter()
openat()

The first two operations will always cause ktrace to report insufficient capabilities. Which is a false-postive statement, and will be misleading for "normal" users.

If I understand correctly, for application like:

localtime();
open();
cap_enter()
openat()

In D40676#958215, @oshogbo wrote:

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

I haven't looked into the code, to be honest. However, I don't see a real application for this approach, or maybe I misread how this is supposed to work.
Is this a tool for improving debugging sandboxed applications or sandboxing new applications?

Again, maybe I just need some more context to understand the reasoning behind this change.

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

In D40676#958207, @theraven wrote:

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

So this traces the system calls that are not on the allowed-in-cap-mode list?

To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

Overall this looks good to me. I wonder if @emaste, @oshogbo or @theraven have any thoughts on it? To summarize the patch very briefly, this lets you ktrace an application that does not run in capability mode, and ktrace will log all events which would have triggered a Capsicum violation.

Fix formatting issue in license text

Use cap_svflags instead of cap_flags when determining kernel ABI with syscallabi().

Change NI_LCF_STRICTRELATIVE to NI_LCF_STRICTREL where applicable.

Use AT_STDIN instead of STDIN_FILENO to force read from stdin in readpassphraseat().

The diff looks good.

• cdfd is no longer a global variable. Instead, it is passed locally per function call.
• Open _PATH_TTY, limit its rights, and use readpassphraseat() instead of readpassphrase().
• Limit stdio instead of just stdin.

In D39009#889101, @jfree wrote:

In D39009#888934, @markj wrote:

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.

I am curious why cdfd would be better suited as a local variable? Namespace pollution doesn't seem to be an issue in a small userspace program and passing it would just add one extra argument to the stack for every function call. Is the idea to isolate its scope?

In D39009#888934, @markj wrote:

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.

This looks good! Three comments:

• I don't like that cdfd is a global variable. I'd rather see it plumbed everywhere that we pass a path, even though that's kind of onerous.
• I think readpassphrase() does not quite work in capability mode. See the implementation in lib/libc/gen/readpassphrase.c - it opens /dev/tty. It does have a fallback path, but I'm not sure how well that works. Could you please try writing a little standalone program that enters capability mode and tries to use readpassphrase()? Depending on how that goes, we may want to add a new variant of that function which takes fds from the caller.
• Have you tried testing with kern.trap_enotcap set to 1? That'll help catch any system calls that might be silently failing because we're in capability mode.

Open current directory, enter capability mode, then use *at() syscalls to extract archive files.

Alter function names and comments for clarity

Rebased

In D38860#887537, @rew wrote:

In D38860#887381, @rew wrote:

https://reviews.freebsd.org/D38858 also needs to be addressed before this patch is committed.

I've dropped my request for changes in D38858 - there's nothing blocking this review from being landed.

In D38860#887381, @rew wrote:

https://reviews.freebsd.org/D38858 also needs to be addressed before this patch is committed.

In D38860#887339, @markj wrote:

Looks like this patch needs to be rebased.

Looks like this patch needs to be rebased.

Moved casper dependency to lib9p.

Added revert commit 966026246e62769f3bcd8247a47fe0f4f0433aba

LGTM.
Do you have commit bit or should I commit this?

@oshogbo okay to commit?