Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

When using become with connect provision on a cis hardened machine, the rsync pulling the test results fails #2496

Closed
carlosrodfern opened this issue Nov 20, 2023 · 5 comments · Fixed by #2510

Comments

@carlosrodfern
Copy link
Contributor

carlosrodfern commented Nov 20, 2023

The cause of this bug is because the test results are owned by root:root when using become and the permissions are --- for others. So when the rsync is executed with the non-root user, it fails because the non-root user doesn't have the needed access. This is the case because on a CIS hardened machine, the umask is set globally to 0027.

I'll be providing a PR.

Steps to Reproduce:

  1. Add umask 0027 to /etc/profile and /etc/bashrc on the targeted machine (e.g. a CentOS Stream 9 QCOW2)
  2. On your host machine: tmt init -t base
  3. On the host mache then run the test: tmt -vv run -a provision --how=connect --guest=<ip> --user=<user> --become --key=<key>

Result (ip=192.168.122.166, user=centos):

    execute
        queued execute task #1: default-0 on default-0
        
        execute task #1: default-0 on default-0
        how: tmt
        exit-first: false
            test: Concise summary describing what the test does
                cmd: ./test.sh
            cmd: rsync --version
        fail: Failed to pull workdir from the guest. This usually means that login as 'centos' to the guest does not work.

        fail: Command 'rsync -s -R -r -z --links --safe-links --protect-args --exclude '/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/backup*' -e 'ssh -oForwardX11=no -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=60 -oServerAliveCountMax=5 -oIdentitiesOnly=yes -i '"'"'~/.ssh/id_rsa'"'"' -S/run/user/1000/tmt/tmpfyr4pxde' [email protected]:/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1 /' returned 23.
    finish
    
        summary: 0 tasks completed

plan failed

The exception was caused by 1 earlier exceptions

Cause number 1:

    execute step failed

    The exception was caused by 1 earlier exceptions

    Cause number 1:

        Command 'rsync -s -R -r -z --links --safe-links --protect-args --exclude '/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/backup*' -e 'ssh -oForwardX11=no -oStrictHostKeyChecking=no -oUserKnownHostsFile=/dev/null -oServerAliveInterval=60 -oServerAliveCountMax=5 -oIdentitiesOnly=yes -i '"'"'~/.ssh/id_rsa'"'"' -S/run/user/1000/tmt/tmpfyr4pxde' [email protected]:/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1 /' returned 23.

        stderr (11 lines)
        ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/ASSERT_STATUSES": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/PHASE_STATUSES": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/PersistentData": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/TestResults": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/clbuff": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/cleanup.sh": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/journal.meta": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/journal.txt": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/journal.xml": Permission denied (13)
        rsync: [sender] send_files failed to open "/var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/journal_colored.txt": Permission denied (13)
        rsync error: some files/attrs were not transferred (see previous errors) (code 23) at main.c(1861) [generator=3.2.7]
        ~~~

The permissions:

ls -lash /var/tmp/tmt/run-134/plans/example/execute/data/guest/default-0/tests/example-1/
total 48K
4.0K drwxr-x---. 3 centos centos 4.0K Nov 21 20:37 .
   0 drwxr-x---. 3 centos centos   23 Nov 21 20:37 ..
4.0K -rw-r-----. 1 root   root     35 Nov 21 20:37 ASSERT_STATUSES
   0 -rw-r-----. 1 root   root      0 Nov 21 20:37 clbuff
   0 -rw-r-----. 1 root   root      0 Nov 21 20:37 cleanup.sh
   0 drwxr-x---. 2 centos centos    6 Nov 21 20:37 data
4.0K -rw-r-----. 1 root   root   2.9K Nov 21 20:37 journal_colored.txt
4.0K -rw-r-----. 1 root   root   2.6K Nov 21 20:37 journal.meta
4.0K -rw-r-----. 1 root   root   2.9K Nov 21 20:37 journal.txt
4.0K -rw-r-----. 1 root   root   2.9K Nov 21 20:37 journal.xml
4.0K -rw-r-----. 1 centos centos  652 Nov 21 20:37 metadata.yaml
4.0K -rw-r-----. 1 root   root    734 Nov 21 20:37 PersistentData
4.0K -rw-r-----. 1 root   root     15 Nov 21 20:37 PHASE_STATUSES
4.0K -rw-r-----. 1 root   root    595 Nov 21 20:37 TestResults
4.0K -rwxr-xr-x. 1 centos centos  316 Nov 21 20:37 tmt-test-topology.sh
4.0K -rwxr-xr-x. 1 centos centos  214 Nov 21 20:37 tmt-test-topology.yaml

As mentioned in the comments, the workaround is to create /var/tmp/tmt ahead of time in the targeted machine and use ACL to override the umask: setfacl -d -m o:r /var/tmp/tmt, or perhaps better: setfacl -d -m o:rX /var/tmp/tmt to ensure directory access when needed.

@carlosrodfern
Copy link
Contributor Author

It looks that it is going to be rather related with the fact that the targeted machine is CIS level 2 hardened.

@carlosrodfern
Copy link
Contributor Author

carlosrodfern commented Nov 20, 2023

CIS hardened machines have the umask set to 027. This is the cause of the issue I posted above.
The workaround is to create the tmt folder fresh ahead of the test and set the acl accordingly for the others:

setfacl -d -m o:r /var/tmp/tmt

@lukaszachy
Copy link
Collaborator

Thanks for filing the issue and looking forward to the PR. What is an easy way to get CIS level 2 hardened VM?

@carlosrodfern
Copy link
Contributor Author

@lukaszachy , this is what I use to harden machines:
https://github.com/orgs/ansible-lockdown/repositories

But it may be reproduceable by just adding umask to the /etc/profile file:
https://github.com/ansible-lockdown/RHEL9-CIS/blob/f56e5d33d9e3a5fc64414832c222b3bc045d26df/tasks/section_5/cis_5.6.x.yml#L83

There is also an ACL change:
https://github.com/ansible-lockdown/RHEL9-CIS/blob/8405e67db24ae0c2389ba5ba7312c02b687b3494/tasks/section_6/cis_6.2.x.yml#L354

@carlosrodfern carlosrodfern changed the title When using become with connect provision, the rsync pulling the test results fails When using become with connect provision on a cis hardened machine, the rsync pulling the test results fails Nov 22, 2023
@carlosrodfern
Copy link
Contributor Author

I added STRs and better description of the problem.

carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Nov 23, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Dec 3, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Dec 3, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Dec 3, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Dec 3, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Dec 3, 2023
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Jan 15, 2024
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Jan 31, 2024
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Feb 22, 2024
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
carlosrodfern added a commit to carlosrodfern/tmt that referenced this issue Feb 23, 2024
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
happz pushed a commit to carlosrodfern/tmt that referenced this issue Feb 23, 2024
In machines with umask set to `0027` it is necessary to
setup an acl to overide it so the workdir root directory
stays multi-user access. This is specially necessary on
machines accessed with a non-root user, that are hardened
to CIS Level 1 guidelines.

Fixes: teemtee#2496
Signed-off-by: Carlos Rodriguez-Fernandez <[email protected]>
@psss psss closed this as completed in 846e58b Feb 29, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants