Page MenuHomeFreeBSD

Initialize "ar_errno" and "ar_retval" fields of struct audit_record to 0
AbandonedPublic

Authored by aniketp on Jun 6 2018, 10:01 PM.
Tags
None
Referenced Files
Unknown Object (File)
Thu, Nov 20, 5:51 PM
Unknown Object (File)
Thu, Nov 20, 5:50 PM
Unknown Object (File)
Thu, Nov 20, 5:50 PM
Unknown Object (File)
Thu, Nov 20, 5:41 PM
Unknown Object (File)
Nov 7 2025, 3:30 PM
Unknown Object (File)
Nov 5 2025, 9:17 AM
Unknown Object (File)
Nov 2 2025, 6:42 AM
Unknown Object (File)
Oct 18 2025, 1:35 PM
Subscribers

Details

Reviewers
asomers
rwatson
Summary

execve(2) & fexecve(2) don't have any return value/status
on succesful invocation. au_errno_to_bsm() then places the
default BSM_ERRNO_UNKNOWN's local errno mapping for
"ar->ar_errno". If the errno is not found in bsm_errnos[] in
bsm_errno.c, then we set it as 0 for successful execution.

Also, a minor grammatical correction in bsm_arg.c

Test Plan

Set the audit mask corresponding to ex audit class and try to
audit a successful execution of execve(2), where the forked
process successfully overlays the calling process, then in the
audit record's return token, you'll get something like this:

return,failure: Unknown error: 201,4294967295

Diff Detail

Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 17091
Build 16951: arc lint + arc unit

Event Timeline

This seems insufficiently deterministic. You're mapping a wide range of possible errnos to 0. I think you should look for a more direct way to determine whether execve succeeded or not.

Place the initialisation of ar_errno and ar_retval in audit.c instead of audit_bsm.c
Also, move the typo corrections to D15702

aniketp retitled this revision from Set ar_errno as BSM_ERRNO_ESUCCESS for execve(2) and fexecve(2) on success to Initialize "ar_errno" and "ar_retval" fields of struct audit_record to 0.Jun 8 2018, 4:06 AM
aniketp set the repository for this revision to rS FreeBSD src repository - subversion.

What do you expect an execve audit record to look like after this change? Could you update D15669 to include the correct expectations (after this fix), with an atf_expect_tc_fail statement?