Problem Parsing DNs with an = in the CN #75

oldpatricka opened this Issue Nov 9, 2011 · 1 comment


None yet

2 participants


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/ Oblaw_97/" gets parsed as "/C=CA/O=Grid/ Oblaw_97/" (Note the escaped '=').

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


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/ Schulz_97/
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/ Schulz_97/
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/ Schulz_97/'
2011-11-09 11:24:25,023 ERROR authorization.DefaultAuthorize [ServiceThread-17,authz:157] Problem in authorization callout Could not find the user /C=CA/O=Grid/ Schulz_97/
at org.globus.workspace.sqlauthz.AuthzDecisionLogic.checkImages(
at org.globus.workspace.groupauthz.DecisionLogic.decide(
at org.globus.workspace.groupauthz.GroupAuthz.isPermitted(
at org.globus.workspace.service.binding.authorization.Callout.isPermitted(
at org.globus.workspace.service.binding.authorization.DefaultAuthorize.authz(
at org.globus.workspace.creation.defaults.CreationManagerImpl.createVMs(
at org.globus.workspace.creation.defaults.CreationManagerImpl.doCreation(
at org.globus.workspace.creation.defaults.CreationManagerImpl.create(
at org.globus.workspace.manager.DelegatingManager.create(
at org.nimbustools.messaging.gt4_0.factory.FactoryResource.create(
at org.nimbustools.messaging.gt4_0.factory.FactoryService.create(
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(
at sun.reflect.DelegatingMethodAccessorImpl.invoke(
at java.lang.reflect.Method.invoke(
at org.globus.axis.providers.RPCProvider.invokeMethodSub(
at Method)
at org.globus.gsi.jaas.GlobusSubject.runAs(
at org.globus.gsi.jaas.JaasSubject.doAs(
at org.globus.axis.providers.RPCProvider.invokeMethod(
at org.apache.axis.strategies.InvocationStrategy.visit(
at org.apache.axis.SimpleChain.doVisiting(
at org.apache.axis.SimpleChain.invoke(
at org.apache.axis.handlers.soap.SOAPService.invoke(
at org.apache.axis.server.AxisServer.invoke(
at org.globus.wsrf.container.ServiceThread.doPost(
at org.globus.wsrf.container.ServiceThread.process(
at org.globus.wsrf.container.GSIServiceThread.process(
Caused by: org.nimbus.authz.AuthzDBException: no such user found /C=CA/O=Grid/ Schulz_97/
at org.nimbus.authz.AuthzDBAdapter.getCanonicalUserIdFromAlias(
at org.nimbus.authz.AuthzDBAdapter.getCanonicalUserIdFromDn(
at org.globus.workspace.sqlauthz.AuthzDecisionLogic.checkImages(
... 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/ Schulz_97/'

Thanks so much.

@priteau priteau was assigned Jun 12, 2012
@priteau priteau added a commit that closed this issue Jun 19, 2012
@priteau priteau 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/  The existing CertDN code would
escape this equal sign and produce Bob Oblaw_97/Email\
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/  In this case, Globus will
recognize it as CN=Bob Oblaw_97/, and fail to find the
DN in gridmap and group-authz.

Changing the CertDN code to be closer to existing Globus code, namely, creates Subject DN strings that Globus can

Closes #75.
@priteau priteau closed this in d1e3c5a Jun 19, 2012
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment