hidepid task fails first time

[jbicha]

Test case with lxd

For more about lxd, see Stephane's tutorials from last year.

1. sudo apt install lxd
2. lxc init ubuntu:16.04 EXAMPLE
3. lxc config set EXAMPLE user.user-data - < cloud-init-config.yml
4. (where cloud-init-config.yml contains a basic bootstrap)basic
5. lxc start EXAMPLE
6. debops init TESTING
7. cd TESTING
8. lxc ls will show you the IP address after the virtual machine boots
9. Edit inventory/hosts to add the IP address
   EXAMPLE ansible_ssh_host=128.66.0.100
10. debops -l EXAMPLE

What happens

The first time I run the debops script, it fails at the hidepid task. The second time I run it, it works.
This fails the first time every time I run a new virtual machine.

TASK [debops.console : Make sure that system group with access to /proc exists]
task path: /home/jeremy/.local/share/debops/debops-playbooks/roles/debops.console/tasks/proc_hidepid.yml:3
ok: [EXAMPLE] => {"changed": false, "gid": 995, "name": "procadmins", "state": "present", "system": true}

TASK [debops.console : Configure /proc with hidepid= in /etc/fstab] ************
task path: /home/jeremy/.local/share/debops/debops-playbooks/roles/debops.console/tasks/proc_hidepid.yml:10
fatal: [EXAMPLE]: FAILED! => {"changed": false, "failed": true, "msg": "Error mounting /proc: mount: cannot remount proc read-write, is write-protected\n"}

[drybjed]

The debops.console role checks POSIX capabilities, looking specifically for cap_sys_admin, to see if it can modify mount points. You can check the current POSIX capabilities on root account by executing the capsh --print command.

It seems that the LXD environment lies about the allowed POSIX capabilities (intentionally or not, I'm not sure). Since the role sees that the cap_sys_admin capability is present, it assumes that it can remount filesystems at will to change the mount point parameters. And the parent host blocks that. See this issue for similar situation.

The consensus seems to be that dropping cap_sys_admin capability is not a good approach and you should check the specific capabilities the system allows you against a given resource, but from skimming that thread it seems that there's no good way to do that from userspace (not sure about current situation).

So, how to solve this? If you give me a reliable way to check if the role can remount filesystems, that should do it. Right now you can mark all hosts under LXD to not configure the hidepid option in /proc manually.

[kcem]

This little workaround works for me:
console_proc_hidepid: "{{ ansible_virtualization_type not in ['lxc'] }}"