Bug 1006611 - sudo: internal error, tried to erealloc3(0) on sudorule with hostgroup
sudo: internal error, tried to erealloc3(0) on sudorule with hostgroup
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: sudo (Show other bugs)
19
x86_64 Linux
unspecified Severity medium
: ---
: ---
Assigned To: Daniel Kopeček
Fedora Extras Quality Assurance
:
Depends On: 1000389
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-10 18:12 EDT by Dean Hunter
Modified: 2015-02-23 18:24 EST (History)
10 users (show)

See Also:
Fixed In Version: sudo-1.8.12-1.fc20
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-02-18 06:18:42 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Dean Hunter 2013-09-10 18:12:06 EDT
Description of problem:

"sudo: internal error, tried to erealloc3(0)" is displayed when I try to use sudo authorized by a sudo rule with a host group.  Rebuild the rule without the host group and specify "--hostcat all" to work around the problem, partially.


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

freeipa-server-3.3.0-2.fc19.x86_64
sssd-1.11.0-0.1.beta2.fc19.x86_64
sudo-1.8.6p7-1.fc19.x86_64

freeipa-server-3.1.5-1.fc18.x86_64
sssd-1.9.5-2.fc18.x86_64
sudo-1.8.6p7-1.fc18.x86_64


How reproducible: Consistent


Steps to Reproduce:

  ipa group-add                desktop-admins --desc "Desktop Administrators"
  ipa group-add-member         desktop-admins --users dean

  ipa hostgroup-add            desktops       --desc "Desktops"
  ipa automember-add           desktops       --type=hostgroup
  ipa automember-add-condition desktops       --type=hostgroup \\
                                              --key=fqdn \\
                                              --inclusive-regex='\.hunter\.org$'

  ipa sudorule-add             desktop-admins --desc "Desktop Administrators"
  ipa sudorule-mod             desktop-admins --cmdcat all
# ipa sudorule-add-host        desktop-admins --hostgroups desktops
  ipa sudorule-mod             desktop-admins --hostcat all
  ipa sudorule-add-option      desktop-admins --sudooption '!authenticate'
  ipa sudorule-add-runasuser   desktop-admins --users root
  ipa sudorule-add-runasgroup  desktop-admins --groups root
  ipa sudorule-add-user        desktop-admins --groups desktop-admins


Actual results:

[dean@desktop2 ~]$ sudo id
sudo: internal error, tried to erealloc3(0)


Expected results:

[dean@desktop2 ~]$ sudo id
uid=0(root) gid=0(root) groups=0(root) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023


Additional info:
Comment 1 Martin Kosek 2013-09-11 03:03:05 EDT
This issue is a bug in sudo, there is a bug filed 1000389. Dan, do you plan fixing this in Fedora 19 any time soon?
Comment 2 Pavel Březina 2013-09-11 05:36:26 EDT
Hi,
I still think it is a duplicate of [1].

Can you send me output of following commands please?

$ nisdomainname
$ getent netgroup desktops
$ cat /etc/nsswitch.conf | grep netgroup

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1000389
Comment 3 Dean Hunter 2013-09-11 08:50:04 EDT
[dean@desktop2 ~]$ nisdomainname
nisdomainname: Local domain name not set

[dean@desktop2 ~]$ getent netgroup desktops
desktops             

[dean@desktop2 ~]$ cat /etc/nsswitch.conf | grep netgroup
netgroup:   files sss

[dean@desktop2 ~]$
Comment 4 Pavel Březina 2013-09-11 09:09:47 EDT
(In reply to Dean Hunter from comment #3)
> [dean@desktop2 ~]$ nisdomainname
> nisdomainname: Local domain name not set

You need to correctly set nisdomainname in order to use netgroups (hostgroups) with sudo.

(In reply to Dean Hunter from comment #3)
> [dean@desktop2 ~]$ getent netgroup desktops
> desktops

You can see here that the hostgroup is currently empty. (This proofs that it is a duplicate of 1000389.)

(In reply to Dean Hunter from comment #0)
>   ipa hostgroup-add            desktops       --desc "Desktops"
>   ipa automember-add           desktops       --type=hostgroup
>   ipa automember-add-condition desktops       --type=hostgroup \\
>                                               --key=fqdn \\
>                                               --inclusive-regex='\.hunter\.org$'

I'm not very familiar with automember, but I think it will not automatically include existing hosts in hostgroup, only newly added hosts. In other words, you need to manually include client machine in the hostgroup.

Martin, can you check the ipa commands please and tell if my suspicion is correct?
Comment 5 Martin Kosek 2013-09-11 09:23:59 EDT
(In reply to Pavel Březina from comment #4)
> (In reply to Dean Hunter from comment #0)
> >   ipa hostgroup-add            desktops       --desc "Desktops"
> >   ipa automember-add           desktops       --type=hostgroup
> >   ipa automember-add-condition desktops       --type=hostgroup \\
> >                                               --key=fqdn \\
> >                                               --inclusive-regex='\.hunter\.org$'
> 
> I'm not very familiar with automember, but I think it will not automatically
> include existing hosts in hostgroup, only newly added hosts. In other words,
> you need to manually include client machine in the hostgroup.
> 
> Martin, can you check the ipa commands please and tell if my suspicion is
> correct?

This is correct. Automember rules only affects new LDAP entries (hosts). If you want to apply the rules also for existing entries, you would need to trigger a special task.

If you want to get more information about the automember tasks, see
https://fedorahosted.org/freeipa/ticket/3752 for RFE to improve add an API to add the automember task
https://fedorahosted.org/389/ticket/20#comment:10 for examples how to trigger the automember task by LDIF
Comment 6 Dean Hunter 2013-09-11 09:51:37 EDT
How do I set nisdomainname?
Comment 7 Rob Crittenden 2013-09-11 09:57:51 EDT
# nisdomainname example.com
Comment 8 Dean Hunter 2013-09-11 17:28:26 EDT
[dean@desktop2 ~]$ nisdomainname hunter.org

[dean@desktop2 ~]$ nisdomainname
hunter.org

[dean@desktop2 ~]$ getent netgroup desktops
desktops              (desktop2.hunter.org,-,hunter.org)

[dean@desktop2 ~]$ grep netgroup /etc/nsswitch.conf
netgroup:   files sss

The problem has been resolved.  

This rule now works as desired:

  ipa group-add                desktop-admins --desc "Desktop Administrators"
  ipa group-add-member         desktop-admins --users dean

  ipa hostgroup-add            desktops       --desc "Desktops"
  ipa automember-add           desktops       --type=hostgroup
  ipa automember-add-condition desktops       --type=hostgroup \\
                                              --key=fqdn \\
                                              --inclusive-regex='\.hunter\.org$'

  ipa sudorule-add             desktop-admins --desc "Desktop Administrators"
  ipa sudorule-mod             desktop-admins --cmdcat all
  ipa sudorule-add-host        desktop-admins --hostgroups desktops
  ipa sudorule-add-option      desktop-admins --sudooption '!authenticate'
  ipa sudorule-add-runasuser   desktop-admins --users root
  ipa sudorule-add-runasgroup  desktop-admins --groups root
  ipa sudorule-add-user        desktop-admins --groups desktop-admins

The requirement for nisdomainname to be set is really not documented very well.  I had seen discussions about sudo rules and host groups on the freeipa-users mailing list but did not understand the discussions until now.  I even asked the mailing list for the latest documentation, but I can not see that this requirement was in any of the references.  So for the next person I offer this script as my solution to configuring a client for IPA and sudo:

# Configure the sssd-sudo client for Fedora 18 or 19

  domainname=$(awk '/^ipa_domain/{print $3}' /etc/sssd/sssd.conf)
  nisdomainname $domainname

  if uname -r | grep fc18 &>/dev/null
  then
    yum --assumeyes install libsss_sudo
  fi

  sed --in-place \
    '/^services:/i sudoers:    files sss' \
    /etc/nsswitch.conf

  sed --in-place \
    '/^services/s/ssh/ssh, sudo/' \
    /etc/sssd/sssd.conf

  if uname -r | grep fc18 &>/dev/null
  then
    hostname=$(awk '/^ipa_hostname/{print $3}' /etc/sssd/sssd.conf)
    server=$(awk '/^ipa_server/{print $3}' /etc/sssd/sssd.conf)
    
    if [ "$server" = "_srv_," ]
    then
      server=$(awk '/^ipa_server/{print $4}' /etc/sssd/sssd.conf)
    fi

    cat >/tmp/sssd <<EOD
krb5_server = $server
ldap_sasl_authid = host/$hostname
ldap_sasl_mech = GSSAPI
ldap_sasl_realm = EXAMPLE.COM
ldap_sudo_search_base = ou=sudoers,dc=example,dc=com
ldap_uri = ldap://$server
sudo_provider = ldap
EOD

    sed -i '/^\[domain\/hunter.org\]/r /tmp/sssd' /etc/sssd/sssd.conf
  fi

  systemctl restart sssd.service
Comment 9 Dean Hunter 2013-09-11 22:19:14 EDT
(In reply to Rob Crittenden from comment #7)
> # nisdomainname example.com

How do I set nisdomainname so that it persists across an operating system restart?
Comment 10 Pavel Březina 2013-09-12 04:04:07 EDT
# echo "NISDOMAIN=xxx" >> /etc/sysconfig/network

...should do the trick.
Comment 11 Dean Hunter 2013-09-12 11:57:58 EDT
Thank you.  That takes care of my problem, except for the documentation.
Comment 13 Dean Hunter 2013-09-12 15:06:08 EDT
Why do you pick one line, that is not sufficient, out of a page that is labeled as applying to Fedora 18 but uses an example from an earlier version of IPA that is not available for Fedora 18 and contains many instructions that no longer apply?

This example specifically configures a Fedora 2.2 client for sudo rules. The configuration file in step d is different, depending on the platform. 

How is someone new to IPA supposed to separate the wheat from the chaff?  Please update the documentation to something that more closely resembles the discoveries of this bug report.
Comment 14 Dean Hunter 2013-09-12 15:33:03 EDT
I am sorry folks, but I still do not seem to have it right:

reboot

Login to Gnome on ipa2 as dean

Open a terminal

[dean@ipa2 ~]$ sudo -l
sudo: internal error, tried to erealloc3(0)

[dean@ipa2 ~]$ nisdomainname
nisdomainname: Local domain name not set

[dean@ipa2 ~]$ su -
Password: 

[root@ipa2 ~]# cat /etc/sysconfig/network
# Generated by anaconda
NETWORKING=yes
NISDOMAIN=hunter.org

[root@ipa2 ~]#
Comment 15 Dmitri Pal 2013-09-12 15:36:40 EDT
> 
> How is someone new to IPA supposed to separate the wheat from the chaff? 
> Please update the documentation to something that more closely resembles the
> discoveries of this bug report.

You are right, we have issues with documentation, but we are also quit thinly stretched supporting people in the community.

Are you willing to spend your cycles contributing to improvement of the upstream documentation? If you are interested we can talk more details offline. You have my email.
Comment 16 Dean Hunter 2013-09-18 10:33:20 EDT
Please help, I do not know what I am doing wrong:

[root@ipa2 ~]# reboot
Write failed: Broken pipe

[dean@host ~]$ sudo ssh root@ipa2
Last login: Wed Sep 18 09:25:49 2013 from host.hunter.org

[root@ipa2 ~]# nisdomainname
nisdomainname: Local domain name not set

[root@ipa2 ~]# cat /etc/rc.d//rc.local
nisdomainname hunter.org

[root@ipa2 ~]#
Comment 17 Alexander Bokovoy 2013-09-18 11:14:03 EDT
Do you have rc-local.service enabled in systemd? It is their equivalent of rc.local processing in SysV.

What does

 systemctl status rc-local.service

say?
Comment 18 Dean Hunter 2013-09-18 13:33:08 EDT
Thank you.  Your clue led me to a new series of Google queries and more arcane system administrator knowledge.

[dean@host ~]$ sudo ssh root@ipa2 reboot
Write failed: Broken pipe

[dean@host ~]$ sudo ssh -X root@ipa2
Last login: Wed Sep 18 12:21:48 2013 from host.hunter.org

[root@ipa2 ~]# nisdomainname
hunter.org

[root@ipa2 ~]# hostname --nis
hunter.org

[root@ipa2 ~]# ls -lZ /etc/rc.d/rc.local
-rwxr-xr-x. root root unconfined_u:object_r:initrc_exec_t:s0 /etc/rc.d/rc.local

[root@ipa2 ~]# cat /etc/rc.d/rc.local
#!/usr/bin/bash

nisdomainname hunter.org

[root@ipa2 ~]# systemctl status rc-local.service
rc-local.service - /etc/rc.d/rc.local Compatibility
   Loaded: loaded (/usr/lib/systemd/system/rc-local.service; static)
   Active: active (exited) since Wed 2013-09-18 12:23:42 CDT; 1min 20s ago
  Process: 625 ExecStart=/etc/rc.d/rc.local start (code=exited, status=0/SUCCESS)

Sep 18 12:23:42 ipa2.hunter.org systemd[1]: Starting /etc/rc.d/rc.local Comp....
Sep 18 12:23:42 ipa2.hunter.org systemd[1]: Started /etc/rc.d/rc.local Compa....
[root@ipa2 ~]# 

Is the requirement for setting nisdomainname in /etc/rc.d/rc.local one of IPA's phased implementation steps?  I am concerned that several sources stated that  rc-local.service is something to be avoided in favor of a specifically designed service.
Comment 19 Alexander Bokovoy 2013-09-18 13:46:00 EDT
This is not really IPA-specific in Fedora as NIS services might be provided by other implementations too.

I think we need to introduce a separate service that would be enabled in compat plugin is enabled or if ypbind service is enabled. For IPA case it should be handled by ipa-client-install -- once we get sudo configuration support there.

Using rc-local.service is one of workarounds right now.

It would make sense to add this information to the IPA ticket regarding sudo integration.
Comment 20 Dean Hunter 2013-09-18 13:52:04 EDT
Is there a ticket I can watch for adding sudo configuration to ipa-client-install?

FYI, Here is what I have now for sudo configuration:

#!/usr/bin/bash

  set -v

# Configure the sssd-sudo client for Fedora 18 or 19

  if uname -r | grep fc18
  then
    yum --assumeyes install libsss_sudo
  fi

  sed --in-place \
    '/^services:/a sudoers:    files sss' \
    /etc/nsswitch.conf

  sed --in-place \
    '/^services/s/ssh/ssh, sudo/' \
    /etc/sssd/sssd.conf

  if uname -r | grep fc18
  then
    hostname=$(awk '/^ipa_hostname/{print $3}' /etc/sssd/sssd.conf)
    server=$(awk '/^ipa_server/{print $3}' /etc/sssd/sssd.conf)
    
    if [ "$server" = "_srv_," ]
    then
      server=$(awk '/^ipa_server/{print $4}' /etc/sssd/sssd.conf)
    fi

    cat >/tmp/sssd <<EOD
krb5_server = $server
ldap_sasl_authid = host/$hostname
ldap_sasl_mech = GSSAPI
ldap_sasl_realm = HUNTER.ORG
ldap_sudo_search_base = ou=sudoers,dc=hunter,dc=org
ldap_uri = ldap://$server
sudo_provider = ldap
EOD

    sed -i '/^\[domain\/hunter.org\]/r /tmp/sssd' /etc/sssd/sssd.conf
  fi

  systemctl restart sssd.service

  domainname=$(awk '/^ipa_domain/{print $3}' /etc/sssd/sssd.conf)

  if [ -f /etc/rc.d/rc.local ]
  then
    cat >/etc/rc.d/rc.local <<EOD
nisdomainname $domainname
EOD
  else
    cat >/etc/rc.d/rc.local <<EOD
#!/usr/bin/bash

nisdomainname $domainname
EOD

    chmod 755 /etc/rc.d/rc.local
    restorecon -v /etc/rc.d/rc.local
  fi
Comment 21 Alexander Bokovoy 2013-09-18 13:55:13 EDT
Here is IPA ticket: https://fedorahosted.org/freeipa/ticket/3358
SSSD has a ticket for native IPA sudo support: https://fedorahosted.org/sssd/ticket/1108
Comment 22 Pavel Březina 2013-09-23 06:19:23 EDT
Changing component to sudo.
Comment 23 Fedora Update System 2014-09-30 11:20:57 EDT
sudo-1.8.11-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.11-1.fc20
Comment 24 Fedora Update System 2014-10-01 00:22:26 EDT
Package sudo-1.8.11-1.fc20:
* should fix your issue,
* was pushed to the Fedora 20 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing sudo-1.8.11-1.fc20'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-11928/sudo-1.8.11-1.fc20
then log in and leave karma (feedback).
Comment 25 Fedora Update System 2014-11-03 09:27:18 EST
sudo-1.8.11p2-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.11p2-1.fc20
Comment 26 Fedora End Of Life 2015-01-09 17:40:06 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 27 Fedora Update System 2015-02-18 05:20:22 EST
sudo-1.8.12-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/sudo-1.8.12-1.fc20
Comment 28 Fedora End Of Life 2015-02-18 06:18:42 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 29 Fedora Update System 2015-02-23 18:24:49 EST
sudo-1.8.12-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.

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