#3741 Samba can not register sss idmap module because it's using an outdated SMB_IDMAP_INTERFACE_VERSION
Closed: Fixed 8 months ago Opened 8 months ago by sbose.

Ticket was cloned from Red Hat Bugzilla (product Red Hat Enterprise Linux 7): Bug 1578291

Description of problem:

  Failed to register idmap module.
  The module was compiled against SMB_IDMAP_INTERFACE_VERSION 5,
  Please recompile against the current version of samba!
 load_module_absolute_path: Module '/usr/lib64/samba/idmap/sss.so'
initialization failed: {Wrong Type}

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

How reproducible:

Steps to Reproduce:

Actual results:

Expected results:

Additional info:

SSSD uses version 5:


while samba-4.7.1 requires version 6:

$ ▶ grep SMB_IDMAP_INTERFACE_VERSION source3/include/idmap.h

Metadata Update from @sbose:
- Custom field rhbz adjusted to https://bugzilla.redhat.com/show_bug.cgi?id=1578291

8 months ago

This issue has also affected Archlinux since a long time. They're patching the correct Interface version, as it depends on the installed Samba version. See Archlinux Project SVN

Archlinux bug was: FS#56723

Technically that is not enough as a signature of the idmap module init function did change as well. It needs to be updated too, even though idmap_sss init function doesn't use the argument and thanks to C calling conventions it is the caller who clears up the stack, so Samba code will behave just fine with the patch in ArchLinux.

Still, this is an incomplete patch. @sbose already has a patch that includes full fix.

@abbra Understood. Looking forward to see the full patch.

The question for me is still how to best supply the corrections. Current Archlinux approach is to patch SSSD until the full patch is released by the SSSD team. On the other hand my current understanding is that both, interface version and signature depend on the installed Samba version. As far as I remember the mismatch is not recognized during SSSD build process but leads to a crash of the idmap_sss process. Please correct me if I'm wrong. So as soon as we implement the patch, SSSD systems that operate an older Samba version will run into troubles. Somehow it would be good, if the mismatch can be catched earlier, e. g. during installation or build process. Any ideas?

The header with this constant is internal to Samba, so we either need to ask for it to be externalized upstream, or find out a way to check if the module works during compile time. I have some ideas about that: one can create a small executable that links against Samba private idmap library, initializes with own smb.conf and calls domain_has_idmap_config("mydomain"); that forces to load idmap_sss. if that one fails, you know your version is different and should be changed, you force break a build.

$ rpm -qf /usr/lib64/samba/libidmap-samba4.so 

Metadata Update from @sbose:
- Issue assigned to sbose

8 months ago

Metadata Update from @sbose:
- Custom field patch adjusted to on

8 months ago

Metadata Update from @fidencio:
- Issue close_status updated to: Fixed
- Issue status updated to: Closed (was: Open)

8 months ago

Commit 095bbe1 relates to this ticket

Metadata Update from @jhrozek:
- Issue set to the milestone: SSSD 1.16.2

8 months ago

Login to comment on this ticket.