stages: add a `sudoers` stage

[supakeen]

An initial implementation of a sudoers stage.

This is currently really basic as in it only takes some placeholders like so:

        {
          "type": "org.osbuild.sudoers",
          "options": {
            "filename": "/etc/sudoers.d/10-test",
            "specifications": [
              {
                "user": "user",
                "host": "ALL",
                "target": "ALL",
                "command": "ALL"
              }
            ]
          }
        }

And formats them into a file.

• [ ] Validate data in fields according to the EBNF of sudo.
• [x] Do we want the types to be arrays and do the joining on , ourselves for User_List, etc
• [ ] Do we want to validate that users/groups actually exist?
• [ ] Do we want to run visudo -cf on the resultant file?

This idea came from the #947 PR.

[supakeen]

With the merge of #1037, this now passes tests (at least locally) so I'm changing this from draft to an actual PR so we can discuss schema and scope.

user@desktopa osbuild € sudo pytest -vv test/run/test_stages.py -k sudoers
=============================== test session starts ===============================
platform linux -- Python 3.10.4, pytest-6.2.5, py-1.11.0, pluggy-1.0.0 -- /usr/bin/python3
cachedir: .pytest_cache
rootdir: /home/supakeen/src/osbuild
plugins: anyio-3.5.0
collected 60 items / 59 deselected / 1 selected                                   

test/run/test_stages.py::TestStages::test_sudoers PASSED                    [100%]

=================== 1 passed, 59 deselected in 85.10s (0:01:25) ===================

[teg]

Does it ever make sense to have these files anywhere else than /etc/sudo.d/? Could we hard code the directory?

[supakeen]

@teg I think the only option I could see is if you want to write /etc/sudoers directly. That's likely a bad plan on the manifest creators side so hardcoding the prefix seems good to me.

[teg]

i think we hardcode the "correct" path in other stages. usually we go for /usr if supported, but not sure if sudo supports that

[supakeen]

• Hardcoded the /etc/sudoers.d path. Changed filename pattern to not allow /.

[bcl]

I think this needs to run visudo -cs on the resulting changes to validate them. Otherwise you can end up with a situation where bad user input may be really difficult to debug.

[supakeen]

@bcl Yea, I feel the same way. I'll add it. Theoretically we should be unable to generate a faulty sudoers file, practically it can probably happen.