Support subid resources in ipa provider

[abbra]

For containerized environments it is helpful to enable centrally-managed allocation and distribution of ID sub-ranges for users/groups to use in podman and runc.

As discussed in shadow-maint/shadow#154, shadow-maint/shadow@0a7888b adds a new interface, libsubid. This interface will be extended to allow pluggable backends.

The purpose of this ticket is to track any work related to libsubid integration.
Corresponding FreeIPA ticket is https://pagure.io/freeipa/issue/8361

[lukasheinrich]

just adding here that his is of interest for deploying containers at CERN. We have successfully tested the state-file based approach which works well, but to deploy this at scale a dynamic solution is needed

[cloudbustinguk]

Seconding @lukasheinrich's interest, but from the Paul Scherrer Institute also in Switzerland.

[cjreyn]

Diamond Light Source also interested in this. Our current solution of building a subuid/subgid list through a cron job querying LDAP is less than ideal!

[alexey-tikhonov]

As discussed in shadow-maint/shadow#154, shadow-maint/shadow@0a7888b adds a new interface, libsubid. This interface will be extended to allow pluggable backends.

Just to makes things clear: this ^^ (support of pluggable backends) wasn't implemented in shadow-utils so far.

Moreover, that's not the only thing that should be done there.
For example, newgidmap/newuidmap should be reworked to make use of this new (pluggable) API instead of files-backed lib/subordinateio (which could be used as a basis for "files" plugin).

Without this SSSD changes doesn't make sense.

Another thing, I don't think it is really realistic to make findutils, coreutils, util_linux, audit, procps and any other tool that looks at process or files using new shadow-utils API in addition to glibc nss to resolve issue of "objects owned by unknown UID/GID". But that's a different story.

[martijndegouw]

just adding here that his is of interest for deploying containers at CERN. We have successfully tested the state-file based approach which works well, but to deploy this at scale a dynamic solution is needed

Are there already LDAP (especially Active Directory) attributes assigned for this info?
Right now I'm considering to just use a extension attribute and store the subuid:count in there.

[abbra]

No, I haven't had time to work on this yet. So no LDAP attributes designed and allocated. I guess we can start with a prototype and then settle down with a registered set of attributes that suit best.

[hallyn]

Hi,

This is purely untested and just meant to start a conversation and show what I think shadow's needs are, but I started a shadow branch here: https://github.com/hallyn/shadow/tree/2020-12-30/sssd latest commit so far being hallyn/shadow@20501b8 .

If you don't expect to have time in the next few weeks to write the sssd side of it, I could give it a shot. I'd of course try to keep it in the style of the rest of sssd, but testing setup would be an initial stumbling block.

[alexey-tikhonov]

Hi,

This is purely untested and just meant to start a conversation and show what I think shadow's needs are, but I started a shadow branch here: https://github.com/hallyn/shadow/tree/2020-12-30/sssd latest commit so far being hallyn/shadow@20501b8 .

If you don't expect to have time in the next few weeks to write the sssd side of it, I could give it a shot. I'd of course try to keep it in the style of the rest of sssd, but testing setup would be an initial stumbling block.

Hi,

first of all, thanks a lot for pushing this forward. Yes, I hope I'll be able to give this a try.

I will take a deeper look in your prototype this week, but from a first glance I have a following question: why do we need any SSSD specific code (i.e. /libmisc/sssd.c) in shadow-utils sources at all?

My understanding is that shadow should read name(-s) of the plugin from /etc/nsswitch.conf::subid field, then dlopen(libsubid_$name) (where name = files may stand for plugin that sources info from local /etc/ files, sss - for SSSD plugin that sources info from LDAP, etc -- but names shoudn't be hardcoded in shadow-util sources) and then dlsym()'s fixed API - independent of plugin being loaded.
I think code in shadow-utils that loads and uses plugin should be the same for any plugin: this simplifies things and allows anyone interested to provide/plug own data sources, besides classical files and IPA/SSSD.
This also somewhat resolves "testing setup" thing: libsubid_files is the very first setup to be tested in new framework.

Btw, I think it's better to follow libsubid_$plugin pattern (instead of lib$plugin_subid currently seen in sources) to be consistent with nss subsystem (libnss_files.so, libnss_sss.so, libnss_systemd.so, etc)

[hallyn]

Yeah I was following the sudo example, I agree shadow doesn't care whether it's sssd or something else.

Actually exporting a libsubid_files.so feels odd, but I'll go ahead and do that.

I'll post here when I've updated the branch per your suggestions. I'm sorry, due to some off-time coming up I'm not sure when I'll be able to. It shouldn't take too long though so when I find a slow afternoon...

[alexey-tikhonov]

Yeah I was following the sudo example, I agree shadow doesn't care whether it's sssd or something else.

Actually exporting a libsubid_files.so feels odd, but I'll go ahead and do that.

Well, from my point of view that's fine, but if you feel it's too weird to export libsubid_files.so then I think it is also ok to have an exception / special handling specifically for /etc/nsswitch.conf::subid=files in internal implementation.

The main point is to have this transparent for users (i.e. configuration means should be the same - etc/nsswitch.conf - for all data sources) and for providers of 3rd party plugins (i.e. no plugin specific handling / changes in shadow-utils code to plug new data source)...

[alexey-tikhonov]

Hi @hallyn,

shadow-maint/shadow#154 (comment) :

I've had a branch for this for awhile but haven't had time to review/test my own code.

Is this https://github.com/hallyn/shadow/commits/2021-01-31/newnss.1 or something different?

[hallyn]

Based on that, but that is a bit out of date.

[hallyn]

Ok I force pushed my current branch to https://github.com/hallyn/shadow/commits/2021-01-31/newnss.1 . I'm sure it needs some cleanup, but it works - passes the little tests I wrote, and I manually tested with a custom libsubid_zzz.so which provides subuid 200000 to my user while /etc/subuid provides 100000. I was able to get and not get the correct ranges based on /etc/nsswitch.conf subid: files versus subid: zzz.

Hoping to proofread and clean it up tonight. In the meantime, comments very welcome in that PR.

[alexey-tikhonov]

Thanks.
Added comments here and inline.

[pbrezina]

Pushed PR: #5693

• master
  • f546088 - Basics of 'subid ranges' support for IPA provider.