The essential message here is that, while we have a few simple short-term plans and more loose longer-term ones, future directions will depend for the most part on current or potential users’ feedback. We are eager to hear suggestions for small improvements or entirely new features, whether you are already using mac_do(4)/mdo(1), are planning to, or would like to but cannot because your use case is not covered by existing functionality. This will help us select what to work on while keeping the overall design sound. Even just saying you’re using them is useful feedback, as it is good to know how many users we have and how they are using these tools.
In the short term, we expect to add auditing-like functionalities to mac_do(4)/mdo(1). Displaying the final credentials passed to the kernel would help check if the invocation was correct with respect to the expected goals. Producing the target part of a mac_do(4)’s rule authorizing exactly a specific mdo(1) call could help administrators build mac_do(4) configurations or better understand why some do not work as expected. Integration to the audit(4) subsystem would allow tracking credentials changes after the fact. Logging failed attempts through syslog(3) would match what login(1) and other credentials-changing program do. mac_do(4) will soon allow configuring the executables whose processes it will consider, with the aim to support thin-jails scenarios and other userland programs
24. It should also monitor traditional system calls such as setuid(2) in addition to just setcred(2), considering each call as a full transition on its own24.
Longer term, we may consider providing su-like and doas-like functionalities, e.g., to ask for a password or perhaps more generally leveraging pam(3), establish resource limits and other attributes as in a full login, or allow only certain commands to be launched. However, it is not yet clear how these functionalities could be fit into mdo(1), as it is not a “setuid executable”, and if different paths should be pursued instead.
