Bug 9203 - build plugin interface for cifs-utils idmapping tools
Summary: build plugin interface for cifs-utils idmapping tools
Status: RESOLVED FIXED
Alias: None
Product: CifsVFS
Classification: Unclassified
Component: user space tools (show other bugs)
Version: 2.6
Hardware: All All
: P5 normal
Target Milestone: ---
Assignee: Jeff Layton
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-09-24 16:58 UTC by Jeff Layton
Modified: 2013-01-07 14:45 UTC (History)
4 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Layton 2012-09-24 16:58:02 UTC
There are a number of changes coming to the idmapping mechanisms for Linux. In particular, the wbclient developers want to move away from needing to configure winbind on the actual clients and have them use SSSD for idmapping instead.

I'm opening this ticket to track some work on redesigning how cifs-utils does idmapping. We'd like to move it away from using the wbclient libs directly, and change over to some sort of plugin interface. Then we could provide a wbclient based backend for idmapping as well as an SSSD one.

The related bug for sssd is here:

   https://fedorahosted.org/sssd/ticket/1534

Obviously, some design work is needed first for this...
Comment 1 Jeff Layton 2012-10-12 16:55:16 UTC
Ok, spent some time looking at this today:

cifs.idmap, getcifsacl and setcifsacl call into wbc libs directly. Those need to be changed to call into a new library that will allow the code to plug in multiple backends.

We'll create a new directory under %_libdir to hold the plugins:

    %_libdir/cifsidmap

...or something. That will hold a set of libraries, plus a symlink called "default" that will point to the correct default lib. Admins can switch between the different plugins by changing where that symlink points.

Each plugin library will have a struct that holds pointers to the different functions that we need the plugin to implement. Each program can resolve that
struct in the lib after it's dlopen'ed so that it knows how to handle the plugin.
Comment 2 Jeff Layton 2012-11-15 21:05:26 UTC
I spent last week cleaning up a horrific number of bugs in the cifs-utils idmapping and ACL tools. I've cut release 5.8 which contains those fixes. Now that we have tools that actually work vs. winbind, it's time to start looking at building this plugin interface.

Here's what I'm thinking for a basic design. We'll declare a directory -- something like /usr/lib[64]/cifs-utils/idmap that will contain plugins for the idmapping interface. Those plugins will be .so objects that will "export" a struct with function pointers that looks something like this:

struct idmap_operations {
        unsigned int version;
        int (*name_to_sid)(char *name, struct cifs_sid *sid);
        int (*sid_to_name)(struct cifs_sid *sid, char *name);
        int (*sid_to_uid)(struct cifs_sid *sid, uid_t *uid);
        int (*sid_to_gid)(struct cifs_sid *sid, uid_t *uid);
        int (*uid_to_sid)(uid_t uid, struct cifs_sid *sid);
        int (*uid_to_sid)(gid_t uid, struct cifs_sid *sid);
};

In the directory, we'll typically have a symlink called "default" that will point to the plugin we'll use by default. We can also allow someone to override that decision and pick a different plugin on the command-line as a future feature.

The plugin interface will open /usr/lib[64]/cifs-utils/idmap/default and use dlsym to find the operations struct. Assuming that succeeds we can then use those operations to do the idmapping.

The operations should be more or less self explanatory. A struct cifs_sid is basically like a struct wbcDomainSid, except that it's "packed" and the subauth fields are in little-endian.

Since the code already supports wbclient, we'll bundle a wbclient-based plugin initially. That should just be a matter of repackaging the existing wbc calls. After that we can add in one for sssd.

Thoughts?
Comment 3 shirishpargaonkar@gmail.com 2012-11-16 03:08:30 UTC
(In reply to comment #2)

>         int (*uid_to_sid)(gid_t uid, struct cifs_sid *sid);

nitpicking; I think you meant gid_to_sid here.

Also, is the functionality in setcifsacl and getcifsacl, esepcially
in setcifsacl deemed enough or there need to be additional options?
Comment 4 Jeff Layton 2012-11-16 10:02:24 UTC
> (In reply to comment #2)
> 
> >         int (*uid_to_sid)(gid_t uid, struct cifs_sid *sid);
> 
> nitpicking; I think you meant gid_to_sid here.
> 

That's not a nitpick. Good catch, I'll fix that...

> Also, is the functionality in setcifsacl and getcifsacl, esepcially
> in setcifsacl deemed enough or there need to be additional options?

Well, the idea is to abstract out the existing wbc functionality used by all 3 tools (getcifsacl, setcifsacl and cifs.idmap) into a plugin interface. Initially we'll just have one plugin that calls into libwbclient to do all of this.

Once that's done, we can use that as a template to add a new plugin based on sssd. The functions in the operations struct should be sufficient for what we have now. The version field should allow us to expand that functionality later. We can add new ops to the end of the struct and bump the version number to indicate their presence.

OTOH, maybe it would be better not to bother with this operations struct? Should we just have the plugin .so files export specific functions directly? If there are compiler differences or something that throw off the alignment of the fields in the struct then that could be problematic.

This is my first stab at building a userland plugin interface for anything, so bear with me while I work through the details... ;)
Comment 5 Jeff Layton 2013-01-02 19:27:28 UTC
Ok, plugin interface has now been discussed upstream and I merged it this morning. I'll probably cut a new cifs-utils release in the next day or two, and at that point I'll close this bug.
Comment 6 Jeff Layton 2013-01-07 14:45:06 UTC
cifs-utils-5.9 is now released and has the new plugin architecture. Closing as RESOLVED FIXED.