ansible-restic
ansible-restic copied to clipboard
paulfantom
Add restic_mode variable
It should be possible to allow all users to run the restic binary. For that the variable restic_mode should be set to 0755 to set the permissions of the file accordingly.
I sometimes want to allow all my users on the system to use the restic binary (mostly Linux Desktop systems). I then need restic to have executable right for other. (Like rsync for example).
Then what is the purpose of using ansible for that? This role is aimed primarily at server usage where you automate your backup configuration (that's why we have those cron file templates) and not at only providing restic binary.
(Sorry for the delay, somehow missed your answer).
I think I get your point, but in our scenario we (the admins) would like to be able to run restic snapshots and the like without sudo permissions.
Or do you think that allowing restic to be run as "ordinary" user is somehow risky? (Changing the mode of the binary is completely optional after all).
I don't see any risk in running restic binary as an ordinary user and changing binary permissions to 0755 seems ok to me. @TheLastProject what do you think?
cap_dac_read_search+ep is set currently, so that would give ANY user read access to ANY file. So we definitely shouldn't unless we make sure that's not set
@TheLastProject Sorry, you lost me here. Why / Where are these capabilities set? Is this somehow specific to restic itself (shall we file a security bug there)?
It's set here: https://github.com/paulfantom/ansible-restic/blob/8fc1da0d33cd89f7ed879d7b4b2467532d765ac1/tasks/install.yml#L77-L82
Normally, it improves security, because restic could run as another user than root but still back up every file, see https://github.com/paulfantom/ansible-restic#security. However, if you give everyone execute permission, this becomes a serious security concern. I'm all for supporting a way to give everyone execute permission, but we need to make sure to unset it then.
Hey @paulfantom, @TheLastProject,
sorry for the very long delay.
What about only setting the capability when the "other" execute permission is not set? (I updated my PR (also rebased it on latest master)).
Well, you'd also want to unset it if that bit is set, otherwise doing a rollout and then deciding "oh nvm I actually want to allow everyone to use it" will still open you to the same security issue.
And: shouldn't we also unset the capability when owner and group are 'root' (again)?
(I so sorry for this comment flood... )
And: shouldn't we also unset the capability when owner and group are 'root' (again)?
(I so sorry for this comment flood... )
Well, yup, we talked about that:
Well, you'd also want to unset it if that bit is set, otherwise doing a rollout and then deciding "oh nvm I actually want to allow everyone to use it" will still open you to the same security issue.
EDIT: Actually I misread. When owner and group are root there are read rights for anything anyway, but it couldn't hurt just for the sake of consistency I suppose.