libnfsidmap2: Virtual domains/users handling with at sign in idmap

Bug #584942 reported by Ramzi HABIB
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
libnfsidmap (Debian)
New
Unknown
libnfsidmap (Ubuntu)
Confirmed
Undecided
Unassigned

Bug Description

Binary package hint: libnfsidmap2

Package: libnfsidmap2
Version: 0.23-2
Severity: normal
Tags: patch

Idmap fails to map uid to localname or vice versa in case an 'at' ( @ ) sign
is included in the localname.
This is particularly the case of virtual domains username where
a user@virtual_domain is in fact the username and its @ sign conflicts with
username@idmap_domain format used by idmap to handle uid/localname conversions.
Where username = user@virtual_domain.
Idmap is still able to map uid/localname correctly when the username does not
include an @ sign.
Both NFS Server and Client are PAM/NSS clients of an OpenLDAP Server that
handles users & groups. NFSv4 is used and without kerberos and "nsswitch"
Translation method is used rather than umich_ldap.
Idmap looks for the first occurrence of and @ sign in the name string
and assumes that the @ sign is the one of user@virtual_domain rather than
using the one of username@idmap_domain (user@virtual_domain@idmap_domain).
The function "strip_domain" is defined in nss.c file and uses "strchr"
function on line 138 to find the first occurrence of an @ sign from the name
string.
As the name string includes 2 occurrences, the domain resulting from that
(virtual_domain@idmap_domain) fails to match with the configured idmap domain
(idmap_domain) and this causes idmap returning a null value.
Switching from "strchr" to "strrchr" simply fix the problem as it would look
for the last occurrence rather than the first one and therefore has a resulting
domain that matched the idmap one.
This obviously makes sense as a URI should be read from right to left and not
from left to right when handling domains.
The idmap domain is this way the root domain and all virtual domains included
in the username it handles will not conflicts with it.

EDIT : An additional fix is needed to fix realm handling in NSSWITCH method in idmapd. This was introduced in version 0.21 and up.
a switch between strstr and strrchr is needed when it comes to search for '@' ( at sign ) in the Realm variable. Similarly to the domain handling.

A patch is included here below :

Patch to fix both domain & principal realm. Applies to :

libnfsidmap2-0.23-2 in lucid
libnfsidmap2-0.21-2 in jaunty
libnfsidmap2-0.21-2 in karmic

libnfsidmap_0.21_up_fix_at_sign_user_with_domain_plus_realm_fix.diff

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

--- libnfsidmap-0.23.orig/nss.c 2009-07-29 22:19:06.000000000 +0200
+++ libnfsidmap-0.23/nss.c 2010-05-11 17:34:03.000000000 +0200
@@ -135,7 +135,7 @@
        char *l = NULL;
        int len;

- c = strchr(name, '@');
+ c = strrchr(name, '@');
        if (c == NULL && domain != NULL)
                goto out;
        if (c == NULL && domain == NULL) {
@@ -276,7 +276,7 @@
                return -EINVAL;

        /* get princ's realm */
- princ_realm = strstr(princ, "@");
+ princ_realm = strrchr(princ, '@');
        if (princ_realm == NULL)
                return -EINVAL;
        princ_realm++;

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

This is the same bug reported at debian but I wasn't able to reply to it with this final patch.

Each time I send a reply to the bug email address, it just doesn't update it.

http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=581199

Here is a patch that applies to versions below 0.21 libnfsidmap where only the domain @ sign fix is needed ( no realm @ sign handling ) :

Patch to fix domain only. Applies to :

libnfsidmap2-0.20-0build1 in intrepid
libnfsidmap2-0.20-1 in hardy

libnfsidmap_0.20-1_fix_at_sign_user_with_domain.diff

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

--- libnfsidmap-0.20.orig/nss.c 2007-02-05 17:13:05.000000000 +0100
+++ libnfsidmap-0.20/nss.c 2010-05-11 14:35:55.000000000 +0200
@@ -135,7 +135,7 @@
  char *l = NULL;
  int len;

- c = strchr(name, '@');
+ c = strrchr(name, '@');
  if (c == NULL && domain != NULL)
   goto out;
  if (c == NULL && domain == NULL) {

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////////

Tags: patch udd-find
Revision history for this message
Ramzi HABIB (ramzi-nomado) wrote :
Revision history for this message
Ramzi HABIB (ramzi-nomado) wrote :

For versions below 0.21 where no realm at sign ( "@" ) handling was introduced yet

tags: added: udd-find
Changed in libnfsidmap (Debian):
status: Unknown → New
Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in libnfsidmap (Ubuntu):
status: New → Confirmed
Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Hi Ramzi, I'm going over this very old libnfsidmap bug now.

Do you know under what situation this part of your suggested patch is needed?
@@ -276,7 +276,7 @@
   return -EINVAL;

  /* get princ's realm */
- princ_realm = strstr(princ, "@");
+ princ_realm = strrchr(princ, '@');
  if (princ_realm == NULL)
   return -EINVAL;
  princ_realm++;

Or is it just a precaution?

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

Specifically, when is nss_gss_princ_to_ids() (via nfs4_gss_princ_to_ids()) called? It doesn't seem to be in the path of the normal nsswitch functions.

Revision history for this message
Andreas Hasenack (ahasenack) wrote :

I'm concentrating the discussion in bug #1819197

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.