Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
Define the following sudo rules in IPA:
dn: cn=sudo-manipulate-application-directory,ou=sudoers,dc=testrelm,dc=test
sudoUser: test-user
sudoRunAsGroup: ALL
objectClass: sudoRole
objectClass: top
sudoOption: !authenticate <<<<<<<<<<<<<<<
sudoOption: !requiretty
sudoCommand: /bin/chmod *[]* /data/*[]*
sudoCommand: /bin/chown *[]* /data/*[]*
sudoCommand: /bin/mkdir /data/*
sudoCommand: /bin/rm -Rf /data/*[]*
sudoCommand: /usr/bin/systemctl restart goferd
sudoCommand: /bin/systemctl restart goferd
sudoCommand: /usr/bin/systemctl restart rsyslog
sudoCommand: /usr/bin/systemctl start rsyslog
sudoCommand: /usr/bin/systemctl stop rsyslog
sudoCommand: !/bin/chown *[]* /data/* *
sudoCommand: !/bin/chown *[]* /data/*..*
sudoCommand: !/bin/mkdir /data/* *
sudoCommand: !/bin/mkdir /data/*..*
sudoCommand: !/bin/rm -Rf /data/* *
sudoCommand: !/bin/rm -Rf /data/*..*
sudoCommand: !/bin/rm -Rf /data/backups
sudoCommand: !/bin/rm -Rf /data/log
sudoCommand: !/bin/rm -Rf /data/spool
sudoRunAsUser: ALL
sudoHost: ALL
cn: sudo-manipulate-application-directory
No password is required when issuing the following command as the test-user:
sudo /usr/bin/systemctl stop rsyslog
Same thing when using the terminal within the cockpit web interface.
However, the user is faced with: "Error Interactive authentication required" message when attempt to start/stop syslog via Services -> rsyslog.service on the cockpit web interface. Is this an expected behavior?
Version-Release number of selected component (if applicable):
cockpit-ws-118-2.el7.x86_64
cockpit-shell-118-2.el7.noarch
cockpit-docker-118-2.el7.x86_64
cockpit-storaged-118-2.el7.noarch
cockpit-118-2.el7.x86_64
cockpit-bridge-118-2.el7.x86_64
How reproducible:
Steps to Reproduce:
1. Define the above sudo rules in IPA replica
2. log onto a IPA client as the "test user", issuing "sudo /usr/bin/systemctl stop/start rsyslog" should all work
3. now log onto cockpit installed on the IPA client as the "test-user", attempt to start/stop rsyslog by browsing to services-> rsyslog.service, you can see the error
Actual results:
Expected results:
Additional info:
Cockpit doesn't use the command line interface to systemd, but the DBUS API [1]. Therefore adding sudo rules for systemctl commands won't affect Cockpit.
Please ensure the permissions for the user are set correctly.
[1] https://www.freedesktop.org/wiki/Software/systemd/dbus/
Note:
In contrast to most of the other services of the systemd suite PID 1 does not use PolicyKit for controlling access to privileged operations, but relies exclusively on the low-level D-Bus policy language. (This is done in order to avoid a cyclic dependency between PolicyKit and systemd/PID 1.) This means that sensitive operations exposed by PID 1 on the bus are generally not available to unprivileged processes directly. However some (such as shutdown/reboot/suspend) are made available via logind's interfaces.