Remote group merging for Fedora

The Problem

One of the major features of the Fedora Server Edition is the Cockpit administrative console. This web-based interface provides administrators with a powerful set of tools for controlling their system. Cockpit relies upon low-level tools like polkit and sudo to make authorization decisions to determine what a user is permitted to do. By default, most operations on a Fedora system are granted to users in the ‘wheel’ group. People granted administrator access to Cockpit (and other tools through shell access) are generally added to the wheel group in the /etc/group file.

This works reasonably well for single-user systems or very small environments where manual edits to /etc/group are maintainable, but in larger deployments, it becomes very unwieldy to manage lots of entries in /etc/group. In these cases, most environments switch over to using some form of a domain controller (such as FreeIPA, Microsoft Active Directory or a custom LDAP setup). These domain controllers allow users to be managed centrally, allowing administrators to make changes in a single place and have this be automatically picked up by all enrolled systems.

However, there is a problem: historically the group processing on Fedora (provided by glibc) has forced users to choose between using centrally managed groups (such as those provided by a domain and maintained by SSSD) or groups maintained on the local system in the /etc/group file. The behavior of glibc is specified in /etc/nsswitch.conf to decide which of the two mechanisms will “win” in the event of a conflict. This means that administrators need to decide up front whether their groups must all come from a domain controller or some locally.

The Solution

Over the last few months, I worked on adding a new feature to the glibc name-service functionality to enable “group merging”. The net effect is that now for all lookups of a group, glibc can be configured to check both the local files and the remote service and (if the group appears in both), combine the list of member users for both representations of the group into a single response.

Thus, it becomes possible to provide both local and central administrators into the wheel group. This can come in handy for example if an administrator wants to keep one or more local accounts available to do disaster recovery in the event that the machine loses access to the remote users (such as a bad update resulting in SSSD not starting).

Of course, this functionality does not come without a cost: because all merging lookups will try both data sources, it can result in a performance hit when operating against groups that otherwise would have been answered only by the local /etc/group file. With caching services like SSSD, this impact should be minimized.

Fedora and glibc upstream

The group merging patch has been submitted to the upstream glibc project but has not yet been merged into a release. It narrowly missed the 2.23 merge window, so it is currently slated for inclusion into glibc 2.24.

However, Carlos O’Donell has taken the patch and applied it to glibc in Fedora Rawhide (which will become Fedora 24), so it will be possible to take advantage of these features first in Fedora 24, before anyone else. (For anyone interested from other distributions, the patch should apply cleanly on 2.23 and likely with minimal effort atop 2.22 as well, since little changed besides this.)

Advertisements

5 thoughts on “Remote group merging for Fedora

  1. No, what it means is that if you create the ‘wheel’ group with ID 10 in FreeIPA, you won’t need to delete it from /etc/group in order to have it respected. The two groups will be merged on the client.

    If you want to use different groups as ‘wheel’ on different machines, you can do this on recent SSSD by setting up ID views in FreeIPA: http://www.freeipa.org/page/V4/Migrating_existing_environments_to_Trust#Group_Overrides

    That way, you could give a group of users wheel membership on some machines but not others. (Note: this carries some performance overhead)

    1. So how is it that it has worked for me for years now? I created a group called wheel with ID 10 on the FreeIPA server and added my user to that group. On the clients, the local administrator account works and so does my remote one. Actually, I just tested and sudo doesn’t work with F23. Any sudo attempt by a local user gets a segfault in libsss_sudo.so in sss_sudo_free_result. I will try to look into that. sudo by a remote user still works. I’m pretty sure policykit usage still works as well because the local administrator does still show wheel in the groups list.

      1. There are two different group lookups. One is the list of groups a user belongs to, the other is the list of users in a group. These are not actually perfectly reflective. The list of groups a user belongs to is handled by the initgroups() call and that has supported merging since time out of mind. This patch makes it so that the reverse lookup is also true: if I do ‘getent group wheel’, it will list both the local and remote users.

        Prior to this patch, if there were any users in the wheel group in /etc/groups, this lookup would only return those. With this new feature, it also checks further sources like SSSD.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s