[Bug 584942] Re: libnfsidmap2: Virtual domains/users handling with at sign in idmap

Andreas Hasenack andreas at canonical.com
Thu Mar 21 18:33:43 UTC 2019


*** This bug is a duplicate of bug 1819197 ***
    https://bugs.launchpad.net/bugs/1819197

I'm concentrating the discussion in bug #1819197

** This bug has been marked a duplicate of bug 1819197
   nss_getpwnam: name 'userX at xx.xx.edu@XX.XX.EDU' domain 'XX.XX.EDU': resulting localname '(null)'

-- 
You received this bug notification because you are a member of Ubuntu
Foundations Bugs, which is subscribed to libnfsidmap in Ubuntu.
https://bugs.launchpad.net/bugs/584942

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

Status in libnfsidmap package in Ubuntu:
  Confirmed
Status in libnfsidmap package in Debian:
  New

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 at virtual_domain is in fact the username and its @ sign conflicts with
  username at idmap_domain format used by idmap to handle uid/localname conversions.
  Where username = user at 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 at virtual_domain rather than
  using the one of username at idmap_domain (user at 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 at 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) {

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

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/libnfsidmap/+bug/584942/+subscriptions



More information about the foundations-bugs mailing list