Add tests for rebase to 1.19.17

[jakub-vavra-cz]

Add test for 'sudo passes SHELL twice'
Add tests for regex in command.
Add some basic sudo tests.

Depends on SSSD/sssd-test-framework#222

Summary by Sourcery

Add and reorganize sudo responder tests, including new coverage for basic sudo usage, regex-based sudo rules, and environment variable handling, while adjusting existing sudo tests and topology configuration.

New Features:

• Introduce a suite of basic sudo responder tests covering users, groups, commands, runas users, and runas groups across multiple topologies.
• Add tests verifying sudo behavior with regex and wildcard patterns in commands and command parameters for sudo 1.9.17p2 and later.
• Add a test ensuring the SHELL environment variable is not duplicated when running sudo for a local user.

Enhancements:

• Refine existing sudo tests by adjusting importance levels, simplifying service user handling, and extending runas user tests to execute actual sudo commands.
• Update sudo negative-cache testing to use the higher-level client user and sudorule helpers instead of direct local file manipulation.
• Adjust topology configuration to drop the bareclient provisioned topology entry in favor of explicit BareClient topology usage in tests.

Tests:

• Expand test coverage for sudo rules refresh, runas user with fully qualified names, and various sudo access control scenarios using the new basic sudo test suite.

[sourcery-ai]

Reviewer's Guide

Refactors and expands SUDO responder tests by introducing a new basic SUDO test suite, adding regression tests for sudo 1.9.17 regex and SHELL behavior, simplifying some existing sudo tests, and adjusting topology/importance and setup patterns to align with the newer sssd-test-framework APIs.

File-Level Changes

Change	Details	Files
Adjust existing sudo responder tests to new setup patterns and importance levels.	Lower importance markers from critical to high or medium on several sudo tests to better reflect their priority. Remove parametrization over sssd_service_user and related non-privileged requirement checks, starting SSSD always as default user. Update sudo rules refresh test to start SSSD without service_user parameter. Switch local-users negative-cache test from direct local user/sudoers file manipulation to framework-level client.user and client.sudorule helpers and simplify SSSD startup configuration.	pytest/tests/test_sudo.py
Introduce a comprehensive basic SUDO behavior test suite that covers users, groups, commands, and runas variants using higher-level helpers.	Create new test_basic module with critical-importance tests for simple sudo access patterns (single/multiple users, groups, combined users and groups). Add tests for multiple commands, blacklisted commands, and different runasuser/runasgroup combinations using client.auth.sudo.run and run_advanced. Centralize sudo-related environment setup via a shared _setup_sudo helper that configures authselect, enables the sudo responder, and starts oddjobd, followed by client.sssd.restart in each test. Include workarounds for AD group name resolution where needed by invoking client.tools.id for relevant users.	pytest/tests/test_basic.py
Add regression tests for sudo 1.9.17p2 behavior around SHELL environment duplication and regex-enabled sudo rules.	Add a test validating that SHELL appears only once in the environment when invoking sudo -iu user-1, conditioned on sudo >= 1.9.17p2. Introduce tests that verify wildcard-style command matching, full regex command matching, and regex in command parameters, all guarded by sudo version and distro-major checks. Use client.user and client.sudorule helpers plus client.auth.sudo.run to exercise and assert allowed/denied sudo commands in these scenarios. Ensure local SSSD and sudo responders are configured before running regex/SHELL tests and rely on BareClient topology.	pytest/tests/test_misc_issues.py
Align topology configuration with new BareClient-based sudo tests.	Remove the bareclient entry from provisioned_topologies in mhc.yaml, relying instead on BareClient topology markers within tests.	pytest/mhc.yaml

---

Tips and commands

Interacting with Sourcery

• Trigger a new review: Comment @sourcery-ai review on the pull request.
• Continue discussions: Reply directly to Sourcery's review comments.
• Generate a GitHub issue from a review comment: Ask Sourcery to create an
  issue from a review comment by replying to it. You can also reply to a
  review comment with @sourcery-ai issue to create an issue from it.
• Generate a pull request title: Write @sourcery-ai anywhere in the pull
  request title to generate a title at any time. You can also comment
  @sourcery-ai title on the pull request to (re-)generate the title at any time.
• Generate a pull request summary: Write @sourcery-ai summary anywhere in
  the pull request body to generate a PR summary at any time exactly where you
  want it. You can also comment @sourcery-ai summary on the pull request to
  (re-)generate the summary at any time.
• Generate reviewer's guide: Comment @sourcery-ai guide on the pull
  request to (re-)generate the reviewer's guide at any time.
• Resolve all Sourcery comments: Comment @sourcery-ai resolve on the
  pull request to resolve all Sourcery comments. Useful if you've already
  addressed all the comments and don't want to see them anymore.
• Dismiss all Sourcery reviews: Comment @sourcery-ai dismiss on the pull
  request to dismiss all existing Sourcery reviews. Especially useful if you
  want to start fresh with a new review - don't forget to comment
  @sourcery-ai review to trigger a new review!

Customizing Your Experience

Access your dashboard to:

• Enable or disable review features such as the Sourcery-generated pull request
  summary, the reviewer's guide, and others.
• Change the review language.
• Add, remove or edit custom review instructions.
• Adjust other review settings.

Getting Help

• Contact our support team for questions or feedback.
• Visit our documentation for detailed guides and information.
• Keep in touch with the Sourcery team by following us on X/Twitter, LinkedIn or GitHub.

[sourcery-ai]

Hey there - I've reviewed your changes and they look great!

Prompt for AI Agents

Please address the comments from this code review:

## Individual Comments

### Comment 1
<location> `pytest/tests/test_misc_issues.py:43` </location>
<code_context>
+    client.sssd.start()
+    result = client.auth.sudo.run("user-1", "Secret123", command="/usr/bin/env")
+    assert result.returncode == 0, "Sudo command failed!"
+    assert result.stdout.count("SHELL") == 1, "Variable SHELL is duplicated!"
</code_context>

<issue_to_address>
**suggestion:** Assertion could be more robust by checking for the exact environment variable format.

Instead of counting 'SHELL' occurrences, check for the exact line 'SHELL=/bin/zsh' or use a regex to verify the variable is present once and correctly formatted.
</issue_to_address>

### Comment 2
<location> `pytest/tests/test_misc_issues.py:35-37` </location>
<code_context>
+        2. Variable SHELL is present only once
+    :customerscenario: True
+    """
+    client.host.ssh.run("dnf install zsh -y")
+    u = provider.user("user-1").add(uid=10001, gid=10001, shell="/bin/zsh")
+    provider.sudorule("test").add(user=u, host="ALL", command="/bin/env")
</code_context>

<issue_to_address>
**suggestion (testing):** Test setup could be made more robust by checking installation success.

Please add an assertion to check the return code of the installation command to confirm zsh was installed successfully before proceeding with the test.

```suggestion
    install_result = client.host.ssh.run("dnf install zsh -y")
    assert install_result.returncode == 0, "Failed to install zsh!"
    u = provider.user("user-1").add(uid=10001, gid=10001, shell="/bin/zsh")
    provider.sudorule("test").add(user=u, host="ALL", command="/bin/env")
```
</issue_to_address>

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[jakub-vavra-cz]

@shridhargadekar I redid all of the assert messages in test_basic to be more descriptive.

[shridhargadekar]

In test_basic.py,
variables u is used only once in each test case. Rest of the test case explicitly uses absolute value of user/group. Do you think sticking to either an explicit value or variable will help the continuity.

Same for a group variable g.

[shridhargadekar]

LGTM