> If extensibility is needed in the context of secauth, it seems that
> the right thing to do is:
> 1) add a way for a process to express the intent to do a reboot
> 2) the secauth framework checks whether the current user is
> authorized to cause this to happen
> 3) if so, a token (perhaps a special file handle) is handed back to
> the process
> 4) add a way to provide that token as context for subsequent syscalls
> [again, in that process]. Secauth uses that context, combined with
> the particular system call, to make its decisions.
As stated, this doesn't provide a way for something like reboot(8) to
prevent itself from being killed partway through its job. As I wrote
upthread recently, I'm not sure this is as much of a problem in the
case of reboot as it's being made out to be, but the basic point is
valid: that when a nonprivileged user starts a complex privileged
operation, it should not necessarily be able to nuke it partway
through. Traditional set-ID bits solve this as a side effect of the
"you can't kill(2) processes that aren't yours" restriction; I'm not
sure what should replace that.
> The "way" in step 4 could be a meta-syscall, sort of
> "(provide-security-context-for-syscall <context> (operation))"
That breaks as soon as a process has been granted two different
capabilities, both of which are needed for a particular operation.
Unless your meta-syscall has a way to take a whole list of
capabilities, that is....