> > 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.
i'd like to point out that doas+kernel semantics are intended to be stronger than what sudo does. And if some finds a way for the kernel to become more strict (further tie-in to process groups maybe?) then we could do that easily and gain the security, as long as there is no further loss in functional use.
