Bug 3504 - Submission without default credential
: Submission without default credential
Status: RESOLVED FIXED
: GRAM
wsrf gram clients
: 4.0.0
: PC Linux
: P3 blocker
: 4.0.1
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-06-20 22:24 by
Modified: 2005-07-05 15:30 (History)


Attachments


Note

You need to log in before you can comment on or make changes to this bug.


Description From 2005-06-20 22:24:00
The proxy in cog.properties points to /tmp/x509... I moved that file to
~/proxy,
without updating cog.properties.

Code:
...
EndpointReferenceType ert = ManagedJobFactoryClientHelper.getFactoryEndpoint(
ManagedJobFactoryClientHelper.getServiceURL("https://plussed.mcs.anl.gov:4000").getURL(),
                    ManagedJobFactoryConstants.DEFAULT_FACTORY_TYPE);
            JobDescriptionType jdt = new JobDescriptionType();
            jdt.setExecutable("/bin/df");
            GramJob job = new GramJob(jdt);
            job.setCredentials(new GlobusGSSCredentialImpl(new
GlobusCredential(
                    "/home/mike/proxy"), GSSCredential.INITIATE_AND_ACCEPT));
            job.submit(ert);
...

Exception:
ERROR [DelegationUtil]  - GSSException: Defective credential detected [Caused
by: Proxy file (/tmp/x509up_u1000) not found.]
 . Caused by AxisFault
 faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
 faultSubcode: 
 faultString: GSSException: Defective credential detected [Caused by: Proxy
file
(/tmp/x509up_u1000) not found.]
 faultActor: 
 faultNode: 
 faultDetail: 
    {http://xml.apache.org/axis/}stackTrace:Defective credential detected.
Caused
by org.globus.gsi.GlobusCredentialException: Proxy file (/tmp/x509up_u1000) not
found.
    at org.globus.gsi.GlobusCredential.<init>(GlobusCredential.java:99)
    at
org.globus.gsi.GlobusCredential.getDefaultCredential(GlobusCredential.java:535)
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createCredential(GlobusGSSManagerImpl.java:115)
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createCredential(GlobusGSSManagerImpl.java:64)
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createContext(GlobusGSSManagerImpl.java:245)
    at org.globus.axis.transport.HTTPSSender.getSocket(HTTPSSender.java:94)
    at
org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:370)
    at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:88)
    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.client.AxisClient.invoke(AxisClient.java:147)
    at org.apache.axis.client.Call.invokeEngine(Call.java:2719)
    at org.apache.axis.client.Call.invoke(Call.java:2702)
    at org.apache.axis.client.Call.invoke(Call.java:2378)
    at org.apache.axis.client.Call.invoke(Call.java:2301)
    at org.apache.axis.client.Call.invoke(Call.java:1758)
    at
org.globus.delegationService.DelegationFactoryPortTypeSOAPBindingStub.getResourceProperty(DelegationFactoryPortTypeSOAPBindingStub.java:1313)
    at
org.globus.delegation.DelegationUtil.getCertificateChainRP(DelegationUtil.java:514)
    at
org.globus.delegation.DelegationUtil.getCertificateChainRP(DelegationUtil.java:472)
    at org.globus.exec.client.GramJob.delegate(GramJob.java:639)
    at
org.globus.exec.client.GramJob.populateJobDescriptionEndpoints(GramJob.java:450)
    at org.globus.exec.client.GramJob.submit(GramJob.java:403)
    at org.globus.exec.client.GramJob.submit(GramJob.java:306)
    at Test.main(Test.java:42)

    {http://xml.apache.org/axis/}hostname:none.mcs.anl.gov

GSSException: Defective credential detected [Caused by: Proxy file
(/tmp/x509up_u1000) not found.]
    at org.apache.axis.AxisFault.makeFault(AxisFault.java:101)
    at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:97)
    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.client.AxisClient.invoke(AxisClient.java:147)
    at org.apache.axis.client.Call.invokeEngine(Call.java:2719)
    at org.apache.axis.client.Call.invoke(Call.java:2702)
    at org.apache.axis.client.Call.invoke(Call.java:2378)
    at org.apache.axis.client.Call.invoke(Call.java:2301)
    at org.apache.axis.client.Call.invoke(Call.java:1758)
    at
org.globus.delegationService.DelegationFactoryPortTypeSOAPBindingStub.getResourceProperty(DelegationFactoryPortTypeSOAPBindingStub.java:1313)
    at
org.globus.delegation.DelegationUtil.getCertificateChainRP(DelegationUtil.java:514)
    at
org.globus.delegation.DelegationUtil.getCertificateChainRP(DelegationUtil.java:472)
    at org.globus.exec.client.GramJob.delegate(GramJob.java:639)
    at
org.globus.exec.client.GramJob.populateJobDescriptionEndpoints(GramJob.java:450)
    at org.globus.exec.client.GramJob.submit(GramJob.java:403)
    at org.globus.exec.client.GramJob.submit(GramJob.java:306)
    at Test.main(Test.java:42)
Caused by: GSSException: Defective credential detected [Caused by: Proxy file
(/tmp/x509up_u1000) not found.]
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createCredential(GlobusGSSManagerImpl.java:120)
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createCredential(GlobusGSSManagerImpl.java:64)
    at
org.globus.gsi.gssapi.GlobusGSSManagerImpl.createContext(GlobusGSSManagerImpl.java:245)
    at org.globus.axis.transport.HTTPSSender.getSocket(HTTPSSender.java:94)
    at
org.apache.axis.transport.http.HTTPSender.writeToSocket(HTTPSender.java:370)
    at org.apache.axis.transport.http.HTTPSender.invoke(HTTPSender.java:88)
    ... 17 more


A similar problem was also present in GT3 Gram clients, but I could find a
quick
and clean solution for that:
SecureServicePropertiesHelper.setCredential(job, credential);

Unfortunately, it doesn't work with GT4. 

Running jobs with non-default credentials is imperative for submission from a
Java-based portal.
------- Comment #1 From 2005-06-21 01:30:11 -------
Sorry, I think I messed up the installation version. I was using older jars.
Here's an updated trace:

Container failed to initialize. Caused by java.lang.Exception: Secure container
requires valid credentials
	at
org.globus.wsrf.container.GSIServiceDispatcher.setupThreadPool(GSIServiceContainer.java:68)
	at org.globus.wsrf.container.ServiceDispatcher.init(ServiceDispatcher.java:112)
	at org.globus.wsrf.container.ServiceContainer.start(ServiceContainer.java:240)
	at org.globus.wsrf.container.ServiceContainer.<init>(ServiceContainer.java:198)
	at
org.globus.wsrf.container.GSIServiceContainer.<init>(GSIServiceContainer.java:44)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
	at
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
	at java.lang.reflect.Constructor.newInstance(Constructor.java:274)
	at
org.globus.wsrf.container.ServiceContainer.createContainer(ServiceContainer.java:135)
	at
org.globus.wsrf.impl.notification.ClientNotificationConsumerManager.startListening(ClientNotificationConsumerManager.java:61)
	at org.globus.exec.client.GramJob.createJobEndpoint(GramJob.java:897)
	at org.globus.exec.client.GramJob.submit(GramJob.java:449)
	at org.globus.exec.client.GramJob.submit(GramJob.java:340)
	at Test.main(Test.java:42)
------- Comment #2 From 2005-06-21 11:09:41 -------
I think you just need to set the proxy location using
etc/globus_wsrf_core/global_security_descriptor.xml.  Details on security
descriptors is here:

http://www-unix.globus.org/toolkit/docs/4.0/security/authzframe/security_descriptor.html#s-authzframe-server-secdesc-descFile
------- Comment #3 From 2005-06-21 11:46:08 -------
In a portal scenario, there is no proxy location. Multiple users should be able
to submit jobs at the same time.
------- Comment #4 From 2005-06-21 12:34:15 -------
I don't understand what you mean by "there is no proxy location".  If the
container does not have access to host credentials, then you do need a proxy.  

Also, WS-GRAM can indeed run jobs as multiple users as long as the container
owner can run sudo as is described in the documentation.

It looks to me from your second comment that you are missing the
containerkey.pem and containercert.pem files in /etc/grid-security.  These are
the default credential locations that the container tries to use.  You either
need to get host credentials and copy them to those files (owned by the
container owner), specify a different location for host credentials you may
already have, or specify a user proxy location.

Basically, the container needs valid credentials to operate in secure mode. 
Whatever credentials you are using for this purpose need to be configured in
global_security_descriptor.xml.
------- Comment #5 From 2005-06-21 12:59:59 -------
> I don't understand what you mean by "there is no proxy location".  If the
> container does not have access to host credentials, then you do need a proxy. 

This container is the container that the client starts in order to receive
notification. The proxy should be inherited from the job proxy. 

> Also, WS-GRAM can indeed run jobs as multiple users as long as the container
> owner can run sudo as is described in the documentation.

This is on the client side. I'm not sure why I should set up sudo on my laptop
just to submit a job.

> It looks to me from your second comment that you are missing the
> containerkey.pem and containercert.pem files in /etc/grid-security.
> ...

On the client side?

> Basically, the container needs valid credentials to operate in secure mode. 
> Whatever credentials you are using for this purpose need to be configured in
> global_security_descriptor.xml.

------- Comment #6 From 2005-06-21 13:45:53 -------
Sorry, I got confused because the original stack trace looks like it's comming
from the service container.  The second one indeed is comming from the client
container.  I looked at the ResourceSecurityDescriptor API, and there doesn't
appear to be a way of setting the actual credential object like the
ClientSecurityDescriptor class (just the credential file paths).  The GramJob
code indeed doesn't attempt to do anything with the credentials specified with
setCredentials() with respect to the notification consumer.  I'm reassigning
this bug as I'm not sure how to remedy the situation.
------- Comment #7 From 2005-06-21 15:36:21 -------
Setting credentials on resource security descriptor can be done using
setSubject
(), after converting credentials to a Subject object. But that is not going to 
solve this issue, since the credentials set will be used only for security when 
a notification comes in. To start up the consumer container, we need to 
configure in credentials. The code as is, allows you to place a container 
security descriptor file name as a part of a Map object used for creating 
NotificationConsumerManager. i.e


Map properties = new HashMap();
              properties.put(ServiceContainer.SERVICE_DESCRIPTOR_FILE,
                             "path to container sec desc file");
              properties.put(ServiceContainer.CLASS,
                         "org.globus.wsrf.container.GSIServiceContainer");
                consumer = NotificationConsumerManager.getInstance(properties)

Requiring file does not work elegantly for this scenario. I will add another 
property such that a ContainerSecurityDescriptor object can be set (so non-
default credentials can be passed in programatically rather than using file 
names).
------- Comment #8 From 2005-06-22 16:51:07 -------
I have committed a fix for this to trunk and waiting for Jarek to review the 
fix before propagating it to branch. But the following can be done to specify 
credentials now:

                Map properties = new HashMap();
                properties
                    .put(ServiceContainer.CLASS,
                         "org.globus.wsrf.container.GSIServiceContainer");
                ContainerSecurityDescriptor desc = 
                    new ContainerSecurityDescriptor();
                GlobusCredential cred = new GlobusCredential("path to proxy");
                SecurityManager manager = 
                    SecurityManager.getManager();
                desc.setSubject(manager.credentialToSubject(cred));      
                properties
                    .put(ServiceContainer.CONTAINER_DESCRIPTOR,
                         desc);
                consumer = NotificationConsumerManager.getInstance(properties);

I think to solve the issue, GRAM needs to add this code, if non-default 
credentials are set. 
------- Comment #9 From 2005-06-22 17:00:40 -------
Would this work if I have two jobs submitted at the same time, using two
different credentials, and inside the same JVM instance?
------- Comment #10 From 2005-06-22 17:06:50 -------
can a test case be developed so we include this in the standard tests just to
make sure?
------- Comment #11 From 2005-06-22 17:12:59 -------
Yes, it ought to work.  Notice the following line in Rachana's code example:

consumer = NotificationConsumerManager.getInstance(properties);

This should get a brand new instance using the properties set up with different
credentials.

I'll try to get code changes in by tomorrow morning and attach the new client
jar for you to try out. If the new jar solves your problem then I will commit
the fixes to the trunk.  I'll need to wait for Rachana's changes to be committed
to the 4.0.1 branch before doing the same.
------- Comment #12 From 2005-06-22 17:21:08 -------
Gregor,

I admit it would be nice, but I think it will be difficult and dangerous to move
around the default proxy file when someone runs the test just to make sure the
embedded container is actually picking up the right cred.  I think as long as
Mihael can verify the fix works then we should be ok.  I doubt the code that
will hopefully fix this will change much.
------- Comment #13 From 2005-06-22 18:10:47 -------
Rachana,

I think your changes broke something.

First of all, I'm getting "if subject is null" when I start up the container.

Secondly, without modifying the client code as you suggested, it seems the
container is picking up my proxy credentials instead of the container
credentials.  I say this because now the client is complaining because it
expected host credentials but got my proxy subject instead.  I verified that I
did not change the globus_security_descriptor.xml file from the default content. 
------- Comment #14 From 2005-06-22 18:27:32 -------
Nevermind on #2. Rebuilding core with Ant wiped out my containerSecDesc entry
in
server-config.wsdd.  Those System.out.prinln() calls should be removed, though.
------- Comment #15 From 2005-06-22 18:41:02 -------
Ok, I lied.  It's stupid for me to put a new jar up since it relies on
Rachana's
commits.  So I'm not going to do that.  I comitted the GramJob changes to the
trunk, so you should be able to just update the globus_java_ws_core and
globus_wsrf_gram_client_java GPT packages, I think.
------- Comment #16 From 2005-06-22 21:43:37 -------
Removed System.outs lines.
------- Comment #17 From 2005-06-23 18:12:47 -------
Works fine with the test case I had.
------- Comment #18 From 2005-06-23 18:17:44 -------
Rachana,

Any idea when those security updates will make it to the 4.0 branch?
------- Comment #19 From 2005-06-24 11:25:35 -------
Changes merged with branch.
------- Comment #20 From 2005-07-05 15:30:50 -------
I forgot to close this bug out.  The GramJob.java changes were added to the 4.0
branch, so nothing more is needed to be done.