module ansible.posix.authorized_key should support the usual owner, group, mode of the file module
ISSUE TYPE
Feature Idea
COMPONENT NAME
ansible.posix.authorized_key
ADDITIONAL INFORMATION
The current behavior of the module regarding ownership and permission of the key file is not documented which lead to confusion (see #379)
From my understanding and not having checked the actual source code, it seems that:
when not existing, the file is created with the user as the file owner
when existing, file permission are untouched
It means that a current workaround is to use the file module to manage the permissions afterwords (or use the copy module with content instead of authorized_key module and forfeit the various validation that this module offers)
The reason that I believe we should be able to manage permissions is to avoid users messing with restrictions that an administrator would like to enforce with key_options, most of them are there to limit the user right which makes allowing the user to modify its permission silly.
Of course an alternative is just improving the documentation and inform about using the file module afterwords to implement such use case.
Of course as well if someone puts too open mode, it will lead to most sshd implementation refuse to use that file in a rather silent manner (in default verbose mode), which could lead to more issues being created.
- name: Set authorized key taken from file
ansible.posix.authorized_key:
user: charlie
state: present
key: "{{ lookup('file', '/home/charlie/.ssh/id_rsa.pub') }}"
key_file_owner: root
key_file_group: charlie
key_file_mode: 0640
SUMMARY
module ansible.posix.authorized_key should support the usual owner, group, mode of the file module
ISSUE TYPE
COMPONENT NAME
ansible.posix.authorized_key
ADDITIONAL INFORMATION
The current behavior of the module regarding ownership and permission of the key file is not documented which lead to confusion (see #379) From my understanding and not having checked the actual source code, it seems that:
It means that a current workaround is to use the file module to manage the permissions afterwords (or use the copy module with content instead of authorized_key module and forfeit the various validation that this module offers)
The reason that I believe we should be able to manage permissions is to avoid users messing with restrictions that an administrator would like to enforce with key_options, most of them are there to limit the user right which makes allowing the user to modify its permission silly.
Of course an alternative is just improving the documentation and inform about using the file module afterwords to implement such use case.
Of course as well if someone puts too open
mode, it will lead to most sshd implementation refuse to use that file in a rather silent manner (in default verbose mode), which could lead to more issues being created.