Skip to content
This repository

Problem Parsing DNs with an = in the CN #75

Closed
oldpatricka opened this Issue November 09, 2011 · 1 comment

2 participants

Patrick Armstrong Pierre Riteau
Patrick Armstrong
Collaborator

When creating VMs that have an '=' in the DN, there seem to be parsing problems, causing it to not be parsed correctly. For example, "/C=CA/O=Grid/OU=westgrid.ca/CN=Bob Oblaw_97/Email=boblaw@univ.ca" gets parsed as "/C=CA/O=Grid/OU=westgrid.ca/CN=Bob Oblaw_97/Email\=boblaw@univ.ca" (Note the escaped '=').

This seems to happen when using the -n, -c, -k flags in nimbus-new-user. The -s flag seems to work.

Patrick Armstrong
Collaborator

More detail from the user who reported the issue:

Firstly, thanks! Due to your help, I have found the magic incanations that work around a probable bug.

I had noticed the escaped equals, and wasn't sure why that was done. That was added automatically when I did the -c -k to nimbus-new-user and it automatically retrieved the DN from the usercert/key.

I did as you suggested (created the user with the exact DN you gave below), and I got the "no authorization policies" message again. Then I ediited the group01.txt file and made the Email= all capitals, then it changed to Request denied, internal issue.

There is something going on with the way the DNs are parsed at some point. Things are inconsistent, the DNs in the various gridmap and group01.txt file appear differently, sometimes, the comma before the Email= field is replaced by a / and other times not. Even one time, I found that all the commas were left except for the one before Email=. Also, I read somewhere in the docs that the key names in the gridmap/group files were case insensitive, but depending on whether it is EMAIL= or Email=, the error changes when trying to run a VM. Here are the two messages with their respective DNs (as listed in the group01.txt file):

DN: /C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/Email=xxx@ucalgary.ca
Problem: Resource request denied: Error creating workspace(s): There are no authorization policies in place for you which is unexpected, please contact administrator.

DN: /C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/EMAIL=xxx@ucalgary.ca
Problem: Resource request denied: Error creating workspace(s): Request denied, internal issue

Also, when it fails with Request denied, there's a stack trace in the logs:

2011-11-09 11:24:25,021 INFO defaults.CreationManagerImpl [ServiceThread-17,create:362] [NIMBUS-EVENT]: Create request for instance from '/C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/EMAIL=xxx@ucalgary.ca'
2011-11-09 11:24:25,023 ERROR authorization.DefaultAuthorize [ServiceThread-17,authz:157] Problem in authorization callout
org.nimbustools.api.services.rm.AuthorizationException: Could not find the user /C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/EMAIL=xxx@ucalgary.ca
at org.globus.workspace.sqlauthz.AuthzDecisionLogic.checkImages(AuthzDecisionLogic.java:274)
at org.globus.workspace.groupauthz.DecisionLogic.decide(DecisionLogic.java:286)
at org.globus.workspace.groupauthz.GroupAuthz.isPermitted(GroupAuthz.java:326)
at org.globus.workspace.service.binding.authorization.Callout.isPermitted(Callout.java:46)
at org.globus.workspace.service.binding.authorization.DefaultAuthorize.authz(DefaultAuthorize.java:136)
at org.globus.workspace.creation.defaults.CreationManagerImpl.createVMs(CreationManagerImpl.java:745)
at org.globus.workspace.creation.defaults.CreationManagerImpl.doCreation(CreationManagerImpl.java:408)
at org.globus.workspace.creation.defaults.CreationManagerImpl.create(CreationManagerImpl.java:384)
at org.globus.workspace.manager.DelegatingManager.create(DelegatingManager.java:244)
at org.nimbustools.messaging.gt4_0.factory.FactoryResource.create(FactoryResource.java:152)
at org.nimbustools.messaging.gt4_0.factory.FactoryService.create(FactoryService.java:101)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:384)
at org.globus.axis.providers.RPCProvider.invokeMethodSub(RPCProvider.java:107)
at org.globus.axis.providers.PrivilegedInvokeMethodAction.run(PrivilegedInvokeMethodAction.java:42)
at java.security.AccessController.doPrivileged(Native Method)
at javax.security.auth.Subject.doAs(Subject.java:415)
at org.globus.gsi.jaas.GlobusSubject.runAs(GlobusSubject.java:55)
at org.globus.gsi.jaas.JaasSubject.doAs(JaasSubject.java:90)
at org.globus.axis.providers.RPCProvider.invokeMethod(RPCProvider.java:97)
at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:281)
at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:319)
at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32)
at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118)
at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83)
at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:450)
at org.apache.axis.server.AxisServer.invoke(AxisServer.java:285)
at org.globus.wsrf.container.ServiceThread.doPost(ServiceThread.java:664)
at org.globus.wsrf.container.ServiceThread.process(ServiceThread.java:382)
at org.globus.wsrf.container.GSIServiceThread.process(GSIServiceThread.java:176)
at org.globus.wsrf.container.ServiceThread.run(ServiceThread.java:291)
Caused by: org.nimbus.authz.AuthzDBException: no such user found /C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/EMAIL=xxx@ucalgary.ca
at org.nimbus.authz.AuthzDBAdapter.getCanonicalUserIdFromAlias(AuthzDBAdapter.java:857)
at org.nimbus.authz.AuthzDBAdapter.getCanonicalUserIdFromDn(AuthzDBAdapter.java:84)
at org.globus.workspace.sqlauthz.AuthzDecisionLogic.checkImages(AuthzDecisionLogic.java:270)
... 33 more
2011-11-09 11:24:25,024 ERROR factory.FactoryService [ServiceThread-17,create:109] Error creating workspace(s): Request denied, internal issue

The final way to make this work was to create the user like this (same as you gave below, but with EMAIL in all-caps:

nimbus-new-user -s '/C=CA/O=Grid/OU=westgrid.ca/CN=David Schulz_97/EMAIL=xxx@ucalgary.ca' xxx@ucalgary.ca

Thanks so much.

Pierre Riteau priteau closed this issue from a commit June 20, 2012
Pierre Riteau Change CertDN to print Subject DN strings similarly to Globus
The CertDN class is used in the new user operation to obtain the Subject
DN when only the CN has been provided, or when an existing certificate
is used.  This Subject DN is printed as the result of the
nimbus-new-user call, and is also added to the gridmap and the
group-authz files.

A problem appeared when a CN was containing an equal sign, such as
Bob Oblaw_97/Email=boblaw@univ.ca.  The existing CertDN code would
escape this equal sign and produce Bob Oblaw_97/Email\=boblaw@univ.ca.
The escaped string would be used for the gridmap and group-authz files.
However, Globus does not use escaped strings internally, and would fail
to match the DN of a service request against these files.

Another bug appears for certificates with emailAddress fields, such as
CN=Bob Oblaw_97/emailAddress=boblaw@univ.ca.  In this case, Globus will
recognize it as CN=Bob Oblaw_97/E=boblaw@univ.ca, and fail to find the
DN in gridmap and group-authz.

Changing the CertDN code to be closer to existing Globus code, namely
org.globus.tools.CertInfo, creates Subject DN strings that Globus can
recognize.

Closes #75.
d1e3c5a
Pierre Riteau priteau closed this in d1e3c5a June 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.