multiplex'd wrote: > From an end-user standpoint, this means that if a user has run a > priviledged command using sudo and then (within the timeout) runs a > script which itself calls sudo, then they will not be prompted to > enter a password as the script is running with the same foreground > process group on the controlling terminal as the first invocation. > However, in the same scenario, doas would prompt for a password > when it is invoked from within the script, as its parent process ID > is different when running under an interactive user shell from when > it's executed in a shell script. (This can also be observed when > building ports with SUDO=doas, as doas is invoked at various points > in the build process under different make (sub)processes, which > results in doas prompting for a password many times.) > > Now, I am running on the assumption that these ioctl()s were > implemented as a kernel-side component of doas's "password timeout" > functionality as observed when using the "persist" configuration > keyword. From that, my question is whether there is any particular > reason for recording the parent process ID in particular as part of > the cookie stored by the persistent authentication ioctl() as opposed > to the process group ID of the calling process's session leader, as > with sudo.
Yes, the difference is intentional. For pretty much exactly the reason you noticed, although perhaps with the opposite result. A successful authentication is not meant to be inherited by any random program or script you run. A) because vague security concerns, but also B) because I think it's weird that a script maybe works if it runs fast enough, but fails if it takes five minutes to get to doas. Like "make; doas make install" works on a fast machine but fails unexectedly on a slower machine. A more robust approach to this problem is to invert privilege. Start as root, then drop to another user.
