Re: sudo + sssd backend on FreeBSD 10.3 client

Hi Todd,

Thanks for the reply.


-----Original Message-----
From: "Todd C. Miller" <[email protected]>
Date: Monday, February 12, 2018 at 2:21 PM
To: Rick Miller <[email protected]>
Cc: "[email protected]" <[email protected]>
Subject: [EXTERNAL] Re: [sudo-users] sudo + sssd backend on FreeBSD 10.3 client

    On Mon, 12 Feb 2018 15:19:35 +0000, "Miller, Vincent \(Rick\) via sudo-users" w
    rote:
    
    > I'm integrating a FreeBSD 10.3 client with FreeIPA using sssd.
    > Everything works fine with the exception of sudo. Upon execution,
    > sudo seems to iterate over /etc/netgroup introducing slow performance
    > particularly with larger files. For example, tests illustrate a
    > delay anywhere from 8 seconds to 2 minutes be fore a password prompt
    > is returned [and the user is permitted to run sudo].
    
    You don't say whether or not your sudoers file uses netgroups.  If
    you are using file-based sudoers (not the LDAP or sss backends),
    sudo will only check netgroup membership if there are netgroups in
    the sudoers file.  If no netgroups are listed in sudoers, sudo won't
    perform any /etc/netgroup lookups directly.

Whoops, the sudoers files does not use netgroups and contains only two rules:

root ALL=(ALL) ALL
%wheel ALL=(ALL) ALL

As described in the blog and forums posts, relevant bits of nsswitch.conf are configured:

# grep sss /etc/nsswitch.conf
group: files sss
passwd: files sss
sudoers: sss files
netgroup: files

As illustrated, NSS’ sudoers database uses sss and file-based sources. If sudo executes innetgr() only when sudoers contains netgroups, it follows that sssd is returning netgroups via NSS’ sudoers database. Based on my research of the IPA project, it seems plausible that netgroups are being returned though currently unconfirmed.

    
    Sudo uses the C library function innetgr() to determine whether or
    not a user or host is a member of the netgroup listed in sudoers.
    There is no API to fetch all the netgroups a specific user or host
    is a member of so this may result in iterating over the netgroup
    file, depending on how FreeBSD implements netgroups.  Unlike most
    systems, FreeBSD implements netgroups as a flat file and not a
    database file.  This means that it must parse the entire netgroup
    file for each netgroup lookup.  For large netgroup files this can
    be very slow.  This is a FreeBSD-specific problem.
    
    > Host configuration is primarily based on my blog post[1], which is
    > largely based on a FreeBSD forum post[2] where NSS configures the
    > netgroup database sources without sss. Linux counterparts configure
    > the netgroup database with sources "files sss" and do not exhibit
    > slow performance. However, configuring the FreeBSD client likewise
    > fails to yield similar results though still permits its use by the
    > user.
    
    So you have put host groups in the local /etc/netgroup file as in
    that forum post?  That may be the source of the slowdown if the
    netgroup file has grown to be large.

I’m confident /etc/netgroup is being iterated. It is populated according to the script on the forum post. truss(1) output illustrates /etc/netgroup being opened and read followed by large numbers of calls to madvise(2) with MADV_FREE, presumably because it has iterated a record that is no longer relevant.

A question I’ve yet to answer is if NSS actually queries sssd for netgroups when NSS is configured with “netgroup: sss” or “netgroup: sss files”. FreeBSD’s NSS is alleged to support arbitrary modules, such as /usr/local/lib/nss_sss.so*.

-- 
Vincent (Rick) Miller
UNIX Systems Engineer
[email protected]


____________________________________________________________
sudo-users mailing list <[email protected]>
For list information, options, or to unsubscribe, visit:
https://www.sudo.ws/mailman/listinfo/sudo-users