#2087 The multicast check is wrong in the sudo source code getting the host info
Closed: Fixed None Opened 6 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

2 years ago

Login to comment on this ticket.