Feature: Support adding users/groups to sudoers

[JustinBacher]

Description I know it's frowned upon (but I'm sure many people do this) I like being able to just type: reboot and not sudo reboot and I also don't like typing in my password in multiple times every time I run commands requiring root.

I suggest adding an option to user.add and group.add that modifies the /etc/sudoers file accordingly.

Manifest Example

- action: group.add
  group_name: testgroup
  sudoer: ALL=(ALL:ALL)

- action: user.add
  fullname: testuser
  username: test
  sudoer: ALL=(ALL) NOPASSWD: ALL

Would result in /etc/sudoers file having these lines added:

%testgroup ALL=(ALL:ALL)
test ALL=(ALL) NOPASSWD: ALL

[JustinBacher]

Is this something I could put a PR in for? Would I want to include windows (ex: making user an administrator? Idk if windows has an equivalent to GNU groups I'll have to look into it)

And if windows is included would it be sudoer for linux and admin for windows? Or would they be aliases for eachother?

[martintc]

I think so long as its an optional field, I am fine with it. The only thoughts I have potentially against it is equivalents for doas and run0. But So long as its an optional field, it probably isn't a big deal to handle it this way.

For the windows question, it is something I have wondered. I have a co-worker looking to contribute who has expressed interest in looking into it since either here recently or soon, a Windows build will hit where Microsoft has their own sudo implementation. Its at least in preview versions. I don't main windows at home and only use it at work for work things. So outside of writing C# code in visual studio, I am pretty clueless on all things Windows. With the exception of a couple areas I squashed windows bugs for almost 2 years ago for comtrya, haha.

So far my thought would be as you hint, sudoer for interfacting with sudo. This can also apply to macOS and the BSDs. If there is a way to achieve it on windows not through their own implementation of sudo, I would have it as a different optional parameter, maybe call it admin? Then if we wanted an equivalent for doas, doaser?

But I do think it makes sense as part of configuration management, if we can create users and groups, we should probably at some point handle being able to do what is needed to configure privilege escalation.

[martintc]

Another thought. Maybe we could tie this in somehow with the where clauses? But that may be a little bit more difficult of a implementation. If you want to consider that, even as just a thought experiment. For users and groups, we could just have a boolean for allow_elevation that if set to true, we can look at the where clause with a where escalation == sudo as an example. Then do as needed? But that may be a little more than is actually needed and not actually be any better.

Another alternative could be action based, then we can kind of copy the provider methodology to support different privilege escalation methods. So, maybe a privilege_management action with an add_user and add_group. Then we can implement providers.

default:

actions:
  - action: privilege_management.add_user
    username: test
    apply: ALL=(ALL) NOPASSWD: ALL

with specifying a provider:

actions:
  - action: privilege_management.add_user
    username: test
    provider: sudo # doas, run0, etc...
    apply: ALL=(ALL) NOPASSWD: ALL

But if you create a PR with the implementation you suggest, I have no problems with it unless someone else has some input?