#2087 The multicast check is wrong in the sudo source code getting the host info
Closed: Fixed None Opened 8 years ago by jhrozek.

Ticket was cloned from Red Hat Bugzilla (product Fedora): Bug 1007475

Description of problem:
Using the ldap attribute sudoHost, users always been refused to execute
a sudo command when the sudoHost is a IPV4 address or subnet.

Version-Release number of selected component (if applicable):
sssd 1.11.0
sudo 1.8.6p7
sssd-ldap 1.11.0
sssd-common 1.11.0

How reproducible:
Always (But only using NetworkManager service... When switching to "network"
service,  this bug disappears ! )

Steps to Reproduce:
1. In OpenLdap, fill a user entry with a "sudoHost" attribute with a subnet:
2. On a fresh Fedora 19 machine which is in the subnet "", and
which has NetworkManager service installed, the user tries to execute the
command "sudo -l"

Actual results:
"User xxxx is not allowed to run sudo on machine"

Expected results:
The user is allowed to run sudo on the machine

Additional info:
This is an old anomaly we face for a long time.
After a little bit of debugging and digging in the code, it seems a filter on
multicast address is wrong in
./src/providers/ldap/sdap_async_sudo_hostinfo.c:242:            if
(IN_MULTICAST(ip4_addr->sin_addr.s_addr)) {
In fact, a conversion with "ntohl" is needed here:
./src/providers/ldap/sdap_async_sudo_hostinfo.c:242:            if
(IN_MULTICAST(ntohl(ip4_addr->sin_addr.s_addr))) {

Without ntohl, the ipv4 addresses or subnets are seen has multicast and
therefore are filtered...

I see that a similar bug has been fixed in February for IPA:

It may also exist another similar bug in
./src/monitor/monitor_netlink.c:613:        return IN_MULTICAST(addr4->s_addr);

You cannot imagine how much i'm looking forward that this bug be corrected :-)

Fields changed

blockedby: =>
blocking: =>
changelog: =>
coverity: =>
design: =>
design_review: => 0
feature_milestone: =>
fedora_test_page: =>
patch: 0 => 1
review: True => 0
selected: =>
testsupdated: => 0

Fields changed

owner: somebody => jhrozek
status: new => assigned

Fields changed

milestone: NEEDS_TRIAGE => SSSD 1.11.1

resolution: => fixed
status: assigned => closed

Metadata Update from @jhrozek:
- Issue assigned to jhrozek
- Issue set to the milestone: SSSD 1.11.1

5 years ago

SSSD is moving from Pagure to Github. This means that new issues and pull requests
will be accepted only in SSSD's github repository.

This issue has been cloned to Github and is available here:
- https://github.com/SSSD/sssd/issues/3129

If you want to receive further updates on the issue, please navigate to the github issue
and click on subscribe button.

Thank you for understanding. We apologize for all inconvenience.

Login to comment on this ticket.