• 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.