rc.subr: Support setting the audit user when starting services

[markj]

Summary

When an unprivileged user restarts a service using, e.g., sudo, the
service runs with the audit user ID set to that of the unprivileged
user. This can have surprising effects: for instance, a user that
restarts a jail that is running sshd will end up with their UID attached
to all audit logs associated with users who log in via that sshd
instance. (sshd will set the audit user, but this is disallowed in
jails by default.)

Add support for rc.conf directives which cause rc to override the audit
user. Specifically, make <name>_audit_user=foo cause the audit user to
be set to "foo" for service <name>. A plain audit_user=foo directive
causes all services to be started as foo.

Note, like other similar rc features, this feature is limited to rc
services which are run by executing a command. Shell functions can't be
wrapped this way.

[0mp]

Looks OK.

Would you also have the time to document NAME_audit_user and audit_user in rc.conf(5)? In particular, the difference between command-based and function-based services is worth documenting.

Thoughts:

• Having a test entry for this functionality would hurt, but I'm not going to block this patch because of that. If you have a moment to add a test, it would be cool.
• Considering that there are more and more functionalities that don't work for function-based services, perhaps rc.subr could detect when an incompatible variable is set for a function-based service and issue a warning. That's out of scope of this PR for sure though.

libexec/rc/rc.subr

937

style nit to match other entries in the list

[markj]

In D53747#1227297, @0mp wrote:

Looks OK.

Would you also have the time to document NAME_audit_user and audit_user in rc.conf(5)? In particular, the difference between command-based and function-based services is worth documenting.

Yes, I will definitely update the man pages.

Thoughts:

• Having a test entry for this functionality would hurt, but I'm not going to block this patch because of that. If you have a moment to add a test, it would be cool.

I will try to add one in a separate revision.

• Considering that there are more and more functionalities that don't work for function-based services, perhaps rc.subr could detect when an incompatible variable is set for a function-based service and issue a warning. That's out of scope of this PR for sure though.

Or we can provide a variable that rc scripts can use when invoking the target start command, e.g., instead of having

foo_start()
{
    /usr/sbin/foo $args
}

we should provide all of the cpuset/setfib/setaudit/etc. invocations in a variable, so the script can run $rc_command_prefix /usr/sbin/foo $args instead. Still not ideal since it requires that each script actually use it. Is there any precedent for such a thing?

[markj]

Update rc.conf.5 too