Making Ansible, Doas and OpenBSD play nicely
Update 11 Jan 2020: The behaviour of doas changed in OpenBSD 6.6 so the environment specification described below is unnecessary. As of 6.6, doas sets HOME and USER to reflect the target user, like sudo. For details see openbsd-tech
A little while ago, OpenBSD replaced sudo in the base system with doas. This transition follows a typical path in the OpenBSD community where a large, difficult to audit daemon or key application is replaced by an auditable and securable alternate implementation. At the same time, features are pruned if they add significant complexity. I don’t need all the features of sudo and I like the simplicity and security of doas so I wanted to switch. I use Ansible to provision and manage my small collection of servers and when version 2.0 added support for privilege escalation via doas (via the become keyword) I started to make my switch. The main use-case in my Ansible playbooks is where I run as root and become my non-admin user so that permissions are set correctly by default, and in this case doas behaves differently…
# /usr/bin/env | grep -E '^(HOME|USER)=' HOME=/root USER=root # sudo -u esteele /usr/bin/env | grep -E '^(HOME|USER)=' USER=esteele HOME=/home/esteele # doas -u esteele /usr/bin/env | grep -E '^(HOME|USER)=' HOME=/root USER=root
The key difference is which environment variables are propagated from the original session. I find doas to be a little unintuitive in this respect, particularly the inability in the new session to write to the directory specified by $HOME and this behaviour causes problems with the Ansible git and the pip tasks. The git task expects $USER to correspond to the effective user id and the pip task expects $HOME to be the home directory of the effective user id. The unexpected doas environment meant the tasks were trying to write files, as my non-admin user, under /root which was unsurprisingly unsuccessful. Fortunately Ansible has a way to specify environment variables for a task and even though it’d be preferable for the become mechanism to take care of this, it’s an effective workaround (albeit a slightly dirty one).
The example below, from my web host playbook, ties the environment specification and the doas become in a block
# doas preserves USER and HOME, which is different to sudo, however by # specifying them as environment variables we can proceed. # USER is required for git, and HOME is required for pip - block: - name: Checkout wordspeak repo git: repo=ssh://git@github.com/edwinsteele/wordspeak.org.git dest=/home/esteele/Code/wordspeak.org - name: Setup nikola virtualenv pip: requirements=/home/esteele/Code/wordspeak.org/requirements.txt virtualenv_command=/usr/local/bin/virtualenv virtualenv=/home/esteele/.virtualenvs/wordspeak_n7 become: True become_method: doas become_user: esteele environment: USER: esteele HOME: /home/esteele
And having tied this together, I can remove the sudo package!
- name: Remove sudo openbsd_pkg: name=sudo-- state=absent