On 2015-08-27 11:16, Theo de Raadt wrote:
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?
My current model is to use my yubikey when sudo'ing. Occasionally I find it
easier to use my password, and I make use of sudo -a passwd. Perhaps the
case for doas is to provide less features and if you need to be able to do
that, it's best to use sudo from ports?
I didn't question whether you are using it. I asked how many people.
Are you avoiding the question by answering "1"? Not all sensitive
software can do everything. That's why the -backrub option from sudo
didn't make it to doas.
I'm torn. I would like -a, for my uses and users. But I don't have a large
installation.
I'm coming back to this (late) because an authserver being unreachable called
my attention to doas not having -a. I thus can't switch to it from the sudo
port (where I presently have a broken -a).
We use 2-factor authn for sudo & doas, as well as for most logins. Presently,
we transport Yubikey and other HOTP strings across RADIUS to an otpd
authserver, and also have local S/Key configured for access when the otpd
authserver is unreachable.
This is on systems with 1200+ user accounts, about 30 active daily. Users
expect that if they can log in as username:radius or username:skey, they
should be able to sudo -a radius or sudo -a skey.
Moving away from Kerberos means possible increasing use of sudo or doas by
regular users to run transfer commands to data archives. For this, it would
be useful if doas supported "-a skey". Then I could just use doas; the
command is otherwise plain enough.
But that's not a lot of users across the entire OpenBSD installed base.
Installing sudo from ports is still an option. I need to debug the -a failure
there now. ;)
Richard
