1686154 – sudorule matching when no host or hostcat set

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.

Bug 1686154 - sudorule matching when no host or hostcat set

Summary: sudorule matching when no host or hostcat set

Keywords:
Status:	CLOSED ERRATA
Alias:	None
Product:	Red Hat Enterprise Linux 8
Classification:	Red Hat
Component:	sssd
Sub Component:
Version:	8.0
Hardware:	Unspecified
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	rc
Target Release:	8.0
Assignee:	Pavel Březina
QA Contact:	ipa-qe
Docs Contact:
URL:
Whiteboard:
Depends On:	1682305
Blocks:
TreeView+	depends on / blocked

Reported:	2019-03-06 20:30 UTC by Scott Poore
Modified:	2020-05-02 19:08 UTC (History)
CC List:	11 users (show)
Fixed In Version:	sssd-2.2.0-1.el8
Doc Type:	If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed:	2019-11-05 22:34:23 UTC
Type:	Bug
Target Upstream Version:
Embargoed:
Dependent Products:

Attachments	(Terms of Use)
sssd logs (902.47 KB, application/gzip) 2019-03-06 20:40 UTC, Scott Poore	no flags	Details
View All

Links
System	ID	Private	Priority	Status	Summary	Last Updated
Github	SSSD sssd issues 4952	0	None	None	None	2020-05-02 19:08:26 UTC
Red Hat Product Errata	RHSA-2019:3651	0	None	None	None	2019-11-05 22:35:26 UTC

Description Scott Poore 2019-03-06 20:30:04 UTC

Description of problem:

An IPA User is allowed to use sudo via a rule even if hostcat is not set and no host or hostgroup is specified.

[root@rhel8-3 sssd]# ipa sudorule-find --all
--------------------
2 Sudo Rules matched
--------------------
  dn: ipaUniqueID=3a149d22-401c-11e9-a1d8-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com
  Rule name: sudorule1
  Enabled: TRUE
  Users: user1
  External host: test.example.com
  Sudo Allow Command Groups: sudogrp1
  Sudo Option: !authenticate
  ipauniqueid: 3a149d22-401c-11e9-a1d8-525400161dcd
  objectclass: ipaassociation, ipasudorule

  dn: ipaUniqueID=ea1491f6-4020-11e9-b545-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com
  Rule name: sudorule2
  Enabled: TRUE
  Users: user2
  Sudo Allow Command Groups: sudogrp1
  ipauniqueid: ea1491f6-4020-11e9-b545-525400161dcd
  objectclass: ipaassociation, ipasudorule
----------------------------
Number of entries returned 2
----------------------------

[root@rhel8-3 sssd]# !ssh
ssh -l user2 $(hostname)
Password: 
Last login: Wed Mar  6 11:08:24 2019 from 192.168.122.83

[user2@rhel8-3 ~]$ sudo -l
[sudo] password for user2: 
Matching Defaults entries for user2 on rhel8-3:
    !visiblepw, always_set_home, match_group_by_gid, always_query_group_plugin, env_reset, env_keep="COLORS DISPLAY HOSTNAME HISTSIZE KDEDIR LS_COLORS", env_keep+="MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS
    LC_CTYPE", env_keep+="LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES", env_keep+="LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE", env_keep+="LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET
    XAUTHORITY", secure_path=/sbin\:/bin\:/usr/sbin\:/usr/bin

User user2 may run the following commands on rhel8-3:
    (root) /bin/mkdir

^^^
Here I expected to see:

Sorry, user user2 may not run sudo on rhel8-3.

Version-Release number of selected component (if applicable):
sssd-client-2.0.0-43.el8.x86_64


How reproducible:
Seems consistent.  Was seen in a test and was reproduced manually.

Steps to Reproduce:
1.  Install IPA Server
2.  Setup sudorule for user without host/hostgroup

ipa user-add user2 --first=f --last=l --password
kinit user2
kdestroy -A
kinit admin
ipa sudorule-add sudorule2
ipa sudocmd-add /bin/mkdir
ipa sudocmdgroup-add sudogrp1 --desc=sudogrp1
ipa sudocmdgroup-add-member sudogrp1 --sudocmds=/bin/mkdir
ipa sudorule-add-allow-command --sudocmdgroups=sudogrp1 sudorule2
ipa sudorule-add-user sudorule2 --users=user2

3.  sudo as user first time without host

ssh -l user2 $(hostname)
sudo -l

4.  Add hostgroup to sudorule and reset sssd

ipa hostgroup-add hostgrp1
ipa hostgroup-add-member hostgrp1 --hosts=$(hostname)
ipa sudorule-add-host sudorule2 --hostgroup=hostgrp1
systemctl stop sssd; sss_cache -E; systemctl start sssd

5.  sudo as user second time with host

ssh -l user2 $(hostname)
sudo -l

6.  remove hostgroup from rule and reset sssd

ipa sudorule-remove-host sudorule2 --hostgroup=hostgrp1
systemctl stop sssd; sss_cache -E; systemctl start sssd

7.  sudo as user third time with host removed from rule

ssh -l user2 $(hostname)
sudo -l


Actual results:

sudo as user third time (7.) works and shows list of commands that are available to run with sudo.

Expected results:

sudo failed with error message about not permitted.

Additional info:

It appears that the first time without the host info is the only time that it rejects the attempt.  After adding and removing the host, it passes when we expect it to fail.

Comment 1 Scott Poore 2019-03-06 20:31:56 UTC

Is the !(memberHost=*) in the ldap search filter below possibly the problem here?   Seems like that forces a True where the rest of the filter is false.  If I drop that from the search, I can see it returns nothing.  This is from the logs:

(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x0400): calling ldap_search_ext with [(&(objectClass=ipasudorule)(ipaEnabledFlag=TRUE)(|(!(memberHost=*))(hostCategory=ALL)(memberHost=fqdn=rhel8-3.example.com,cn=computers,cn=accounts,dc=example,dc=com)(memberHost=cn=ipaservers,cn=hostgroups,cn=accounts,dc=example,dc=com)(memberHost=cn=hostgrp1,cn=hostgroups,cn=accounts,dc=example,dc=com))(|(cn=sudorule2)))][cn=sudo,dc=example,dc=com].
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [objectClass]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cn]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaUniqueID]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaEnabledFlag]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoOpt]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAs]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsGroup]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberAllowCmd]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberDenyCmd]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberHost]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [memberUser]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotAfter]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoNotBefore]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [sudoOrder]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [cmdCategory]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [hostCategory]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [userCategory]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsUserCategory]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsGroupCategory]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUser]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtGroup]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [ipaSudoRunAsExtUserGroup]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [externalUser]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x1000): Requesting attrs: [entryUSN]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_ext_step] (0x2000): ldap_search_ext called, msgid = 79
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_op_add] (0x2000): New operation 79 timeout 6
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: end of ldap_result list
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_ENTRY]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_entry] (0x1000): OriginalDN: [ipaUniqueID=ea1491f6-4020-11e9-b545-525400161dcd,cn=sudorules,cn=sudo,dc=example,dc=com].
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [objectClass]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [cn]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaUniqueID]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [ipaEnabledFlag]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberAllowCmd]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [memberUser]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_parse_range] (0x2000): No sub-attributes for [entryUSN]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_result] (0x2000): Trace: sh[0x5638faa54bd0], connected[1], ops[0x5638faa2fee0], ldap[0x5638faa06cb0]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_process_message] (0x4000): Message type: [LDAP_RES_SEARCH_RESULT]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x0400): Search result: Success(0), no errmsg set
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_get_generic_op_finished] (0x2000): Total count [0]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_op_destructor] (0x2000): Operation 79 finished
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [sdap_search_bases_ex_done] (0x0400): Receiving data from base [cn=sudo,dc=example,dc=com]
(Wed Mar  6 11:08:26 2019) [sssd[be[example.com]]] [ipa_sudo_fetch_rules_done] (0x0040): Received 1 sudo rules

Comment 3 Scott Poore 2019-03-06 20:40:57 UTC

Created attachment 1541592 [details]
sssd logs

Comment 4 Pavel Březina 2019-03-07 11:18:54 UTC

There was a patch that addressed the same issue in ldap provider, similar should be done for ipa:
https://github.com/SSSD/sssd/commit/47ad0778be72994a2294b2e73cc5c670be6811a7

I'd like to check with sudo maintainers first.

Radovan, what is the expected behavior if sudoHost attribute is missing in LDAP? From what I seen in my testing years ago, it should be:
- if rule is cn=defaults, then use it even if it does not have sudoHost attribute
- if it is any other rule, then require sudoHost attribute

Is this correct expectation?

Comment 5 Daniel Kopeček 2019-03-07 11:29:31 UTC

(In reply to Pavel Březina from comment #4)
> There was a patch that addressed the same issue in ldap provider, similar
> should be done for ipa:
> https://github.com/SSSD/sssd/commit/47ad0778be72994a2294b2e73cc5c670be6811a7
> 
> I'd like to check with sudo maintainers first.
> 
> Radovan, what is the expected behavior if sudoHost attribute is missing in
> LDAP? From what I seen in my testing years ago, it should be:
> - if rule is cn=defaults, then use it even if it does not have sudoHost
> attribute
> - if it is any other rule, then require sudoHost attribute
> 
> Is this correct expectation?

There is no expected behavior because sudoHost is a required attribute of a sudoRole:

"""
Each attribute listed above should contain a single value, but there may be multiple instances of each attribute type. A sudoRole must contain at least one sudoUser, sudoHost and sudoCommand.
"""

Comment 6 Pavel Březina 2019-03-07 14:17:51 UTC

Thank you.

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3980

Upstream PR:
https://github.com/SSSD/sssd/pull/770

Comment 12 Jakub Hrozek 2019-03-13 22:38:16 UTC

Upstream ticket:
https://pagure.io/SSSD/sssd/issue/3980

Comment 13 Jakub Hrozek 2019-03-19 23:04:42 UTC

    master: 3b0ff29
    sssd-1-16: e2f00ae

Comment 14 Jakub Hrozek 2019-04-18 11:22:13 UTC

Scott, can you qa_ack the bug so that it gets auto-mirrored to Jira?

Comment 18 anuja 2019-08-19 07:18:36 UTC

Verified Using Version :
-----------------------------------------------------------
ipa-client-4.8.0-8.module+el8.1.0+3977+ec23ef34.x86_64
ipa-server-4.8.0-8.module+el8.1.0+3977+ec23ef34.x86_64
sssd-ipa-2.2.0-11.el8.x86_64
-----------------------------------------------------------
Test-console logs from given test: comment #17
-----------------------------------------------------------

2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] ::   Removing hostgroup and verifying from sudo client
2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
2019-08-16T18:39:16+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:16 ] :: [  BEGIN   ] :: Running 'ipa sudorule-remove-host sudorule1 --hostgroup=hostgrp1'
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho]   Rule name: sudorule1
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho]   Enabled: TRUE
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho]   Users: user1
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho]   Sudo Allow Commands: /bin/mkdir
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] ---------------------------
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] Number of members removed 1
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] ---------------------------
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:17 ] :: [   PASS   ] :: Command 'ipa sudorule-remove-host sudorule1 --hostgroup=hostgrp1' (Expected 0, got 0)
2019-08-16T18:39:18+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:17 ] :: [  BEGIN   ] :: Running 'ipa hostgroup-del hostgrp1'
2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] ----------------------------
2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] Deleted hostgroup "hostgrp1"
2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] ----------------------------
2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:18 ] :: [   PASS   ] :: Command 'ipa hostgroup-del hostgrp1' (Expected 0, got 0)
2019-08-16T18:39:19+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:18 ] :: [  BEGIN   ] :: Running 'rm -rf /var/lib/sss/db/*;systemctl restart sssd;sleep 3'
2019-08-16T18:39:22+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:22 ] :: [   PASS   ] :: Command 'rm -rf /var/lib/sss/db/*;systemctl restart sssd;sleep 3' (Expected 0, got 0)
2019-08-16T18:39:23+0000 [ci-vm-10-0-154-199.h] *** Current Time: Fri Aug 16 14:39:23 2019 Localwatchdog at: Fri Aug 16 16:26:23 2019
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Password for user1: 
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Ticket cache: KCM:0:4273
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Default principal: user1
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] Valid starting       Expires              Service principal
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] 08/16/2019 14:39:29  08/17/2019 14:39:29  krbtgt/TESTRELM.TEST
2019-08-16T18:39:29+0000 [ci-vm-10-0-154-67.ho] spawn ssh -l user1 ci-vm-10-0-154-67.testrelm.test
2019-08-16T18:39:34+0000 [ci-vm-10-0-154-67.ho] *** Current Time: Fri Aug 16 14:39:34 2019 Localwatchdog at: Fri Aug 16 16:26:34 2019
2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Activate the web console with: systemctl enable --now cockpit.socket
2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Last login: Fri Aug 16 14:38:58 2019 from 10.0.154.67
2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] Could not chdir to home directory /home/user1: No such file or directory
2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] [user1@ci-vm-10-0-154-67 /]$ sudo -l > /tmp/sudo_list_client_27703.out 2>&1
2019-08-16T18:39:35+0000 [ci-vm-10-0-154-67.ho] [sudo] password for user1: 
2019-08-16T18:39:37+0000 [ci-vm-10-0-154-67.ho] [user1@ci-vm-10-0-154-67 /]$ 
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] Connected to ci-vm-10-0-154-67.testrelm.test.
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] Fetching /tmp/sudo_list_client_27703.out to /tmp/sudo_list.out
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]      ---- [/tmp/sudo_list.out] ----
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]     | Sorry, user user1 may not run sudo on ci-vm-10-0-154-67.
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]      ------------------------------
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]      ---- [/tmp/sudo_list.out] ----
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]     | Sorry, user user1 may not run sudo on ci-vm-10-0-154-67.
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho]      ------------------------------
2019-08-16T18:39:47+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:47 ] :: [   PASS   ] :: File '/tmp/sudo_list.out' should contain 'Sorry, user user1 may not run sudo on' 
2019-08-16T18:39:48+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:47 ] :: [  BEGIN   ] :: Running 'ipa sudorule-add-host sudorule1 --hosts=ci-vm-10-0-154-67.testrelm.test'
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho]   Rule name: sudorule1
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho]   Enabled: TRUE
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho]   Users: user1
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho]   Hosts: ci-vm-10-0-154-67.testrelm.test
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho]   Sudo Allow Commands: /bin/mkdir
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] -------------------------
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Number of members added 1
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] -------------------------
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] :: [ 14:39:48 ] :: [   PASS   ] :: Command 'ipa sudorule-add-host sudorule1 --hosts=ci-vm-10-0-154-67.testrelm.test' (Expected 0, got 0)
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ::   Duration: 32s
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ::   Assertions: 5 good, 0 bad
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ::   RESULT: PASS (Removing hostgroup and verifying from sudo client)
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] ** Removing-hostgroup-and-verifying-from-sudo-client PASS Score:0
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] use_pty:FALSE /usr/share/restraint/plugins/run_task_plugins /usr/share/restraint/plugins/run_plugins
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] <no matches>
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Uploading avc.log 
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] .done
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] Uploading resultoutputfile.log 
2019-08-16T18:39:49+0000 [ci-vm-10-0-154-67.ho] .done


Based On this marking bz as verified.

Comment 21 errata-xmlrpc 2019-11-05 22:34:23 UTC

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHSA-2019:3651

Note You need to log in before you can comment on or make changes to this bug.