Bug 988875 - Problem with correct sudorule assigning across hostgroups
Summary: Problem with correct sudorule assigning across hostgroups
Alias: None
Product: Fedora
Classification: Fedora
Component: freeipa
Version: 20
Hardware: Unspecified
OS: Linux
Target Milestone: ---
Assignee: Rob Crittenden
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2013-07-26 15:27 UTC by s.zemlyanoy
Modified: 2013-10-01 07:04 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2013-10-01 07:04:42 UTC
Type: Bug

Attachments (Terms of Use)

Description s.zemlyanoy 2013-07-26 15:27:58 UTC
Description of problem:

Assigning of new hosts to sudorule by adding it to hostgroup doesn't apply appropriate rule. On another hand assigning this host explicitly to sudorule without any hostgroup end up with successfull rule applying.

Version-Release number of selected component (if applicable):

How reproducible:
add new host to hostgroup wich is assigned to some sudorule

Steps to Reproduce:

Actual results:
as workaround should join host explicitly to sudorule

Expected results:
adding host to hostgroup should apply relevant sudorule

Additional info:

Comment 1 Rob Crittenden 2013-07-26 17:41:23 UTC
hostgroups are represented as netgroups to a client so you need to be sure that getent netgroup <hostgroup> returns a correct triple and you need to set nisdomainname on the client to your domain.

Comment 2 Martin Kosek 2013-07-30 09:29:12 UTC
Note that there is an upstream ticket to all these steps automatically. It is planned to be included in next release:

At this point, one needs to do the manual configuration as Rob wrote in Comment 1. s.zemlyanoy, did the change help?

Comment 3 s.zemlyanoy 2013-08-08 15:34:49 UTC
I reproduced the issue more detailed. I installed IPA replica and then added this host to hostgroup which should allow sudo command. But it seems that indirect membership of host in sudorule causes the problem, because when I add host directly to sudorule - it works fine for me.  And now this problem occured only on this replica host.

getent netgroup <hostgroup>    returns corresponding ldap group

Comment 4 Martin Kosek 2013-08-08 15:50:22 UTC
Ok, (In reply to s.zemlyanoy from comment #3)
> getent netgroup <hostgroup>    returns corresponding ldap group

Ok, I assume this works for you now.

Do you also have "sss" for "sudoers" database in /etc/nsswitch.conf and properly set "nisdomainname"?

SUDO won't recognized the netgroup content without that.

Comment 5 s.zemlyanoy 2013-08-09 09:07:12 UTC

So it appears that 'nisdomainname' was not set for host in question. But after I've set it the problem retained. Please review the listing of nsswitch.conf file below:

passwd:     files sss
shadow:     files sss
group:      files sss

#hosts:     db files nisplus nis dns
hosts:      files dns

# Example - obey only what nisplus tells us...
#services:   nisplus [NOTFOUND=return] files
#networks:   nisplus [NOTFOUND=return] files
#protocols:  nisplus [NOTFOUND=return] files
#rpc:        nisplus [NOTFOUND=return] files
#ethers:     nisplus [NOTFOUND=return] files
#netmasks:   nisplus [NOTFOUND=return] files

bootparams: nisplus [NOTFOUND=return] files

ethers:     files
netmasks:   files
networks:   files
protocols:  files
rpc:        files
services:   files sss

netgroup:   files sss

publickey:  nisplus

automount:  files
aliases:    files nisplus

# from IPA
sudoers:        files ldap

Comment 6 Martin Kosek 2013-08-09 09:19:58 UTC
Can you try changing:
sudoers:        files ldap
sudoers:        files sss

to enable SSSD support in SSSD? Lets see if that makes any difference. This is the recommended integration method for FreeIPA&SUDO.

Comment 7 s.zemlyanoy 2013-08-09 09:35:09 UTC
I changed it and got such message

$ sudo less /var/log/messages
sudo: Unable to dlopen /usr/lib64/libsss_sudo.so: (null)
sudo: Unable to initialize SSS source. Is SSSD installed on your machine?

On all the rest hosts this string is set to:
sudoers:        files ldap

so I'm not sure that it's problem

Comment 8 Martin Kosek 2013-08-09 10:09:14 UTC
Ah, sorry for confusion, it should have been "sssd" instead of sss. I did not realize that sudoers is a special case in nsswitch.conf. There is more info on enabling sudo with sssd here:

(In reply to s.zemlyanoy from comment #7)
> so I'm not sure that it's problem

This is probably not the root cause, I was just interested if routing sudo integration through SSSD instead of native LDAP would change the outcome.

I am not experienced with ldap backend for SUDO, adding needinfo on Pavel to advise.

Comment 9 Rob Crittenden 2013-08-09 14:39:49 UTC
I think setting the SUDOERS_DEBUG to 2 is a good next step from the ldap side.

Comment 10 Pavel Březina 2013-08-21 09:56:16 UTC
to enable sssd for sudo, it should indeed say "sss" in nsswitch.conf. However, libsss_sudo package has to be installed, to get the missing library. There will be also more configuration needed, depending on your sssd version (1.9 or 1.10), please see 'man sssd-sudo'.

But I'm not really convinced that switching to sssd backend instead of ldap will help, since the steps for evaluating netgroups are the same.

The debug output as Rob suggested will be helpful.

Please put the following line into /etc/ldap.conf:
sudoers_debug 2

And following line into /etc/sudo.conf
Debug sudo /var/log/sudo_debug all@warn

And send us output of sudo command and /var/log/sudo_debug.


Comment 11 Fedora End Of Life 2013-09-16 14:51:39 UTC
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:

Comment 12 Martin Kosek 2013-09-25 10:53:52 UTC
Hello s.zemlyanoy, did you manage to get the required data as suggested by my colleagues in Comment 9 and Comment 10? Or have you resolved the issue?

If we do not have enough data to understand or reproduce the issue, we would have to close this bug.

Comment 13 Martin Kosek 2013-10-01 07:04:42 UTC
Closing the bug. Please feel free to reopen it in case you hit the issue again.

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