> > Sorry, I think adding an option is too much. I just committed halex's o= > riginal > > diff to only change the type. I thought he was going to do that by now.= > > > > > Hi Ted, > > The thing is, my patch doesn't do the same thing at all as the one which > adds auth-doas. My patch lets the user choose which authentication he > wants, while the other patch lets the admin restrict which auth is used. > > There are 2 very different use cases for this. Let's take an example > with yubikey. > > - The small patch is used by the admin to force yubikey for doas, while > the user could login with a password. > > - My patch with the option lets the user choose. The example would be a > server with an encrypted home directory. When everything is working > correctly, the user can login with, for example, a ssh key and then use > doas with a (non yubi) password. But if the server has crashed for > whatever reason and /home is not mounted, the only way to login would be > with the yubikey because the ssh key is not available and remote login > with normal passwords is disabled. The option replicates how sudo was > working.
doas is a one of the few setuid programs. It should try to do a little bit less functionality, because "doing less" is part of the security model. How many users of that functionality will there be? We only need to concern ourselves with the cost; you have to justify the benefit. How many people were doing this with sudo, and how many will need this with doas?
