Hi all, In the last couple of days I've been studying sudo(8) and doas(1) to find out how they work and what their operational differences are. With regards to storing persistent cookies, to allow a user to execute further commands without reauthentication (subject to a timeout), sudo uses a timestamp file and doas uses verified auth ioctls on the controlling tty.
However, sudo and doas differ in the information stored in the persistent cookie. sudo records the ID of the foreground process group on the controlling terminal while doas records the parent process ID, according to the description of TIOCSETVERAUTH in tty(4). >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. Regards.
