1. 41

  2. 10

    The new persist feature fills in the only thing (except for insults) I missed from sudo. For my uses, that’s 100% of the functionality for less than 9% of the code.

    1. 7

      I wish doas would tell me about the usual lecture from the local system administrator.

      I wish it would report incidents to an unknown entity.

      Other than that, it’s a much better alternative to sudo. I really like it so far.

      1. 3

        They are logged to syslog, its your decision what you do with logs, there are ways to filter and forward them ;).

      2. 4

        FWIW, and especially for those running the just-released 6.0, persist is only available in -current.

        1. 2

          I really enjoyed the first time i used doas. The interface is very self explanatory.

          1. 2

            Anyone using doas in FreeBSD? I just tried it and got an interesting bug (I think).

            permit :wheel

            This let’s me do doas pkg list and works fine

            permit :wheel
            permit nopass :wheel cmd pkg

            I would expect this to let me run pkg commands without a password, which it does, but I get no output. doas pkg list takes awhile since it is printing a lot of stuff out to the screen, but I never see it on the screen with the second rule.

            Anyone else running FreeBSD and see this?

            1. 4

              Looks like there was a bug that would close stdout if nopass was set.

              1. 1

                Nice, thanks!

            2. 2

              Great, I added persist do /etc/doas.conf in 5.9 which apparently doesn’t support it. Now whenever I try to run doas it drops an error:

              $ doas vi /etc/doas.conf 
              syntax error at line 1

              I’m now locked out from the root account. Any easy solution to this, which doesn’t involve disassembling the machine and attaching the disk to another computer to edit doas.conf?

              Instead of “doas mastery” I’ve performed “doas foolery”

                1. 2

                  Thanks, I totally forgot about single user mode!

                2. 3

                  This is one strength to visudoers, it does a little syntax check before saving.

                  1. 1

                    You can copy the doas.conf file before editing and verify that its correct by running doas -C doas.conf cmd args..., it prints the matching rule, e.g. permits, permits nopass.

                  2. 2


                    1. 1

                      I had a passwordless root account, but I managed to reset it by booting into single user mode

                    2. 2

                      I see you already have some suggestions on how to recover. I can offer that a higher-level approach like Ansible or Puppet really has the potential to increase the reliability of your systems. Not only can you force an overall configuration check with Ansible before deploying, you can also use the -C feature to test that certain commands are allowed or not allowed.

                      Or an alias like:

                      f=`mktemp` && doas cp /etc/doas.conf $f && $EDITOR $f && doas -C $f && doas cp $f /etc/doas.conf
                    3. 2

                      Additionally, the authentication information includes the parent shell process ID. This means that executing doas again in a shell script will require authentication. Or, to repeat that another way, if you run a script or program of uncertain quality, it won’t be able to silently elevate privileges.

                      Unless it uses exec().

                      1. 1

                        You know, I (and others, even) specifically considered that, but then I somehow convinced myself that the execed process would still have a different parent. :(

                        There’s a reason the official documentation doesn’t explain this point. That way it can’t be wrong. :)

                      2. 1

                        The way the persists feature is implemented is very smart and its the first feature that is really not portable, though I fully understand the decision to avoid sudo like timestamp/cookie/ticket files. One thing I wonder is, why it doesn’t have a login-backoff sleep as described in login.conf(5), is it considered useless?

                        1. 1

                          Linux-PAM has a pam_timestamp module which could be used to provide this feature, but there is no way to use the pam api to open a session as the target user while authenticating the requesting user without breaking the pam_timestamp module.