Bug 5457 - Misbehaviour of globus-gridmap-and-execute
: Misbehaviour of globus-gridmap-and-execute
Status: RESOLVED FIXED
: GRAM
general
: 4.0.3
: PC Linux
: P3 blocker
: 4.0.6
Assigned To:
:
:
:
: 5695
  Show dependency treegraph
 
Reported: 2007-07-24 11:01 by
Modified: 2007-12-06 14:58 (History)


Attachments


Note

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


Description From 2007-07-24 11:01:10
Hi all!

I am wondering if the below described behaviour is really a bug or not. What I
have got so far:

My grid-mapfile in /etc/grid-security/certificates contains the following
mapping

dt0031@udo-gt01:/usr/local/globus/var> grep -i freitag
/etc/grid-security/grid-mapfile
"/O=GermanGrid/OU=Uni-Dortmund/CN=Stefan Freitag" hp0007,dt0031

So my DN is mapped to two local accounts hp0007 and dt0031 on the node
udo-gt01. I expected that I can submit with globusrun-ws jobs as one or the
other user by specifying the localUserId.

Here are my two test jobs:
1)
<job>
<localUserId>dt0031</localUserId>
<executable>/usr/bin/id</executable>
<directory>/tmp</directory>
<stdout>/tmp/stdout</stdout>
<stderr>/tmp/stderr</stderr>
<queue>dgiseq</queue>
</job>

2)
<job>
<localUserId>hp0007</localUserId>
<executable>/usr/bin/id</executable>
<directory>/tmp</directory>
<stdout>/tmp/stdout</stdout>
<stderr>/tmp/stderr</stderr>
<queue>dgiseq</queue>
</job>

The only difference between the jobs is the localUserId.
Now, when I submit the jobs to Globus I get for

1)
freitag@udo-gt01:~/jobs/xml/id> globusrun-ws -submit -F udo-gt01 -Ft PBS  -s -f
id_dt0031.xml
Submitting job...Done.
Job ID: uuid:74a29c36-39fe-11dc-a4db-0050560bd129
Termination time: 07/25/2007 15:56 GMT
Current job state: Failed
Destroying job...Done.
globusrun-ws: Job failed: Error code: 201
Script stderr:
dt0031 is not in the grid mapfile

2)
freitag@udo-gt01:~/jobs/xml/id> globusrun-ws -submit -F udo-gt01 -Ft PBS  -s -f
id_hp0007.xml
Submitting job...Done.
Job ID: uuid:7a30c024-39fe-11dc-98f5-0050560bd129
Termination time: 07/25/2007 15:56 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
uid=25007(hp0007) gid=20005(hp)
groups=20000(glite),20001(globus),20002(unicore),20005(hp)
context=user_u:system_r:unconfined_t
Current job state: CleanUp
Current job state: Done
Destroying job...Done.


I was surprised about this result and inspected the ongoing things...
After doing a "su" I tried the following from the local account dt0031

dt0031@udo-gt01:/usr/local/globus/var>
/usr/local/globus/libexec/globus-gridmap-and-execute -g
/etc/grid-security/grid-mapfile /bin/date
dt0031 is not in the grid mapfile

and then for hp0007

hp0007@udo-gt01:/usr/local/globus/var>
/usr/local/globus/libexec/globus-gridmap-and-execute -g
/etc/grid-security/grid-mapfile /bin/date
Tue Jul 24 17:59:00 CEST 2007

All in all I came to the result, that there is something strange with
globus-gridmap-and-execute

Do you have any idea what went wrong?

Best regards
Stefan
------- Comment #1 From 2007-07-24 11:37:56 -------
Stefan,
i'm not really familiar with the grid-mapfile syntax, but is
it written somewhere that you can specify local users in a
comma separated way?
It works for me if I add a complete <DN,local user id> mapping
for each local user id.
Following your example it would look like this:
"/O=GermanGrid/OU=Uni-Dortmund/CN=Stefan Freitag" hp0007
"/O=GermanGrid/OU=Uni-Dortmund/CN=Stefan Freitag" dt0031

Please send things like this to one of our email-lists first
when you're not sure whether it's really a bug or not.
Other users can benefit from you experiences then too.

Martin
------- Comment #2 From 2007-07-24 13:25:35 -------
The comma separated syntax has been around a long while (cannot find doc
reference from a quick search though).  

I think g-g-e is not doing the reverse lookup correctly (if the intent is to
match how other Globus components resolve DN to usernames).
------- Comment #3 From 2007-10-25 06:05:44 -------
Hi there,

since this bug also appears in GT 4.0.5 and play an important role for our
purposes in the D-Grid initiative (www.d-grid.de) I just added a few new
informations.

Still looking for support / solution 

What happened on our system (gt 4.0.5):

First of all globus is running fine anyway, but I have to provide for one DN 
more than one unix account. Here I used the command line tool 
grid-mapfile-add-entry. After doing so, my grid-mapfile looks like this:

"/O=XXXXX/OU=XXXXXX/CN=XXXXX XXXX" hp0007,dt0031
my organisation,name and also two unix accounts

While trying to submit a job using the second unix account dt0031 via
globusrun-ws I get 

==== snipp ====
globusrun-ws  -submit -F udo-gt01.grid.uni-dortmund.de -Ft PBS  -f 
hello2.xml -s
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:e46660ca-82d8-11dc-a0c9-0050560bd129
Termination time: 10/26/2007 09:01 GMT
Current job state: Failed
Destroying job...Done.
Cleaning up any delegated credentials...Done.
globusrun-ws: Job failed: Error code: 201
Script stderr:
dt0031 is not in the grid mapfile
==== snipp ====

After looking around a little bit I found that the errors results from a call 
of ./globus-gridmap-and-execute which gets the correct grid-mapfile for use, 
but tells my when I do 

dt0031@udo-gt01:/usr/local/globus/libexec> ./globus-gridmap-and-execute
/bin/date
dt0031 is not in the grid mapfile

but

hp0007@udo-gt01:/usr/local/globus/libexec> ./globus-gridmap-and-execute
/bin/date
Thu Oct 25 11:11:06 CEST 2007

So, for one of the entries the command globus-gridmap-and-execute works and 
for the other not. (As you have seen, both unix accounts are in the 
grid-mapfile)



Another user was able to reproduce this behaviour and found out , why this
happens:

Yes, I can reproduce the same problem here, and the reason is in 
gridmap.c:

        if((gline_tmp->user_ids != NULL) &&
           (gline_tmp->user_ids[0] != NULL) &&
           (strcmp(local_user, gline_tmp->user_ids[0]) == 0))
        {
            found = 1;
        }

Evidently, it only compares the FIRST user id from each line. Maybe you 
should file a bug report.

Regards,
Jan Ploski
------- Comment #4 From 2007-10-26 08:40:48 -------
*** Bug 5640 has been marked as a duplicate of this bug. ***
------- Comment #5 From 2007-10-26 14:21:17 -------
I talked to a C developer and it seems like globus-gridmap-and-execute (which
is called as part of the job submission to the local resource manager) calls
an inappropriate function. There seem to be different ways to fix it.
The problem however is not in gridmap.c

However there's a way to get around that in the meantime:

Section 3.1.1 on 
http://www.globus.org/toolkit/docs/4.0/execution/wsgram/admin-index.html
says:
"The globus-gridmap-and-execute program is used to ensure that
GRAM only runs programs under accounts that are in the grid-mapfile.
In the sudo configuration, it is the first program called. It looks
up the account in the grid-mapfile and then runs the requested
command. It is redundant if sudo is properly locked down. This tool
could be replaced with your own authorization program."

Here's how globus-gridmap-and-execute gets called during job submission
to the local resource manager (fork in this example)

/usr/bin/sudo -H -u feller \
   -S /opt/GT/libexec/globus-gridmap-and-execute \
   -g /etc/grid-security/grid-mapfile \
   /opt/GT/libexec/globus-job-manager-script.pl \
   -m fork \
   -f /opt/GT/tmp/gram_job_mgr34129.tmp \
   -c submit

The call to globus-gridmap-and-execute can be saved by setting a
flag in the environment variable GLOBUS_OPTIONS
Since WS-GRAM already does a gridmap lookup to get the local user
id anyway this second lookup is not really necessary, but more a sanity
check.

Example how to configure GT to skip the second gridmap check (bash):
1. Stop GT container
2. export GLOBUS_OPTIONS="$GLOBUS_OPTIONS -Dorg.globus.exec.disablegge=true"
3. Start GT container

With this the additional gridmap check by the globus-gridmap-and-execute is
skipped and having a comma separated list of local users in the grid-mapfile
works fine.

Judge yourself if this is an intermediate solution for you until we fix it
or if the skipped gridmap check is crucial for you.
------- Comment #6 From 2007-10-26 14:52:54 -------
Hi, 

I think this is a nice workaround. 
I have two comments:

(1) Has it been confirmed that setting

     export GLOBUS_OPTIONS="$GLOBUS_OPTIONS -Dorg.globus.exec.disablegge=true"

    bypasses the invocation of globus-gridmap-and-execute?


(2) If the answer to (1) is yes, then I believe that /etc/suoders 
    must be modified to insert the new invocation, without
    globus-gridmap-and-execute.

Gabriel





do in fact disable the check in 
------- Comment #7 From 2007-10-26 15:06:40 -------
ad 1: yes. here's how the new submission looks like
      /usr/bin/sudo -H -u feller
        -S /opt/GT/libexec/globus-job-manager-script.pl -m pbs \
        -f /opt/GT/tmp/gram_job_mgr61514.tmp -c submit

ad 2: good point. don't know yet why it works for me.
------- Comment #8 From 2007-10-26 15:28:09 -------
Heh, my sudo configuration is nice: some lines above the container
user (martin) was allowed to run all commands:

martin          ALL=(ALL)       NOPASSWD: ALL

No wonder that it worked.

After i removed that line, submission failed as Gabriel suspected.
It starts working again when i remove
"/opt/GT/libexec/globus-gridmap-and-execute -g /etc/grid-security/grid-mapfile"
from the NOPASSWD command in /etc/sudoers

Mike already created a patch so that you might not need to
make use of the above for a long time.
------- Comment #9 From 2007-10-26 16:18:50 -------
This package should fix the problem:
http://www-unix.mcs.anl.gov/~mlink/bugs/globus_gss_assist-3.24.tar.gz

Use the update installation instructions at
http://www.globus.org/toolkit/advisories.html

Let me know how that works for you.
------- Comment #10 From 2007-10-29 04:42:43 -------
I have set the property org.globus.exec.disablegge=true, restarted 
the container and verified that the property is set:

/usr/lib/java//bin/java 
  -Dlog4j.configuration=container-log4j.properties  \
  -DGLOBUS_LOCATION=/lrz/sys/globus \
  -Djava.endorsed.dirs=/lrz/sys/globus/endorsed \   
  -DGLOBUS_HOSTNAME=a01.hlrb2.lrz-muenchen.de \
  -DGLOBUS_TCP_PORT_RANGE=20000,25000 \
  -Djava.security.egd=file:///dev/urandom \
  -Dorg.globus.exec.disablegge=true \
  -classpath /lrz/sys/globus/lib/bootstrap.jar:\
/lrz/sys/globus/lib/cog-url.jar:/lrz/sys/globus/lib/axis-url.jar \
  org.globus.bootstrap.Bootstrap \
  org.globus.wsrf.container.ServiceContainer -p 8443


However, the system property org.globus.exec.disablegge seems to have 
no effect on JobManagerScript() in exec/JobManagerScript.java, 
which still invokes globus-gridmap-and-execute. 

Looking in the code exec/JobManagerScript.java I see that 
the use of globus-gridmap-and-execute is controlled by 
the boolean authzGridmap


   boolean authzGridmap = AuthorizationHelper.isAuthorizationGridmap();
    ...

   if (authzGridmap)
            {
                commandVector.add(gridMapAndExecute);
                if (gridMapFile != null)
                {
                    commandVector.add("-g");
                    commandVector.add(gridMapFile);
                }
            }

    ...

so I looked in org/globus/exec/service/utils/AuthorizationHelper.java 
where there is this code fragment:


     if (authzPDPNames[index].equals(GRIDMAP_AUTHZ_PDP_NAME))
                    {
                        logger.debug("Using gridmap authorization PDP
plugin.");
                        AuthorizationHelper.authorizationGridmap = true;

                    }

and enabling debugging shows in container.log:

$ grep PDP var/container.log
2007-10-29 11:14:24,339 DEBUG utils.AuthorizationHelper [main,initialize:48]
getting authz PDP name
2007-10-29 11:14:24,346 DEBUG utils.AuthorizationHelper [main,initialize:57]
Detected authorization PDP plugin "gridmap".
2007-10-29 11:14:24,347 DEBUG utils.AuthorizationHelper [main,initialize:62]
Using gridmap authorization PDP plugin.

So setting org.globus.exec.disablegge=true does not cause 
authzGridmap to be false. 


This leads to two questions:

 1. Is org.globus.exec.disablegge still supported in GT 4.0.5?

 2. If yes, then is there something else that needs to be 
    set to avoid the invocation of globus-gridmap-and-execute?
    To clarify this issue, what is the relation between setting 
    the system property Dorg.globus.exec.disablegge and the 
    test 

        authzPDPNames[index].equals(GRIDMAP_AUTHZ_PDP_NAME)

    in the above excerpt from AuthorizationHelper.java?

(In reply to comment #7)
> ad 1: yes. here's how the new submission looks like
>       /usr/bin/sudo -H -u feller
>         -S /opt/GT/libexec/globus-job-manager-script.pl -m pbs \
>         -f /opt/GT/tmp/gram_job_mgr61514.tmp -c submit
> 
> ad 2: good point. don't know yet why it works for me.
> 
------- Comment #11 From 2007-10-29 08:17:08 -------
Gabriel,
i apologize for that, i worked on code from trunk which will
be 4.2 and thought the disablegge flag would be the same in 4.0.5.
But it isn't. I should have worked more thoroughly here.
Regardless of this: Did you try the package Mike provided? This
should solve this topic by fixing the lookup in the grid-mapfile.
------- Comment #12 From 2007-10-29 08:50:05 -------
Subject: Re:  Misbehaviour of globus-gridmap-and-execute

Hi,

I will do it next. I had tried first the "easy way".

Thanks.
Gabriel

On 10/29/07, bugzilla-daemon@mcs.anl.gov <bugzilla-daemon@mcs.anl.gov> wrote:
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=5457
>
>
>
>
>
> ------- Comment #11 from feller@mcs.anl.gov  2007-10-29 08:17 -------
> Gabriel,
> i apologize for that, i worked on code from trunk which will
> be 4.2 and thought the disablegge flag would be the same in 4.0.5.
> But it isn't. I should have worked more thoroughly here.
> Regardless of this: Did you try the package Mike provided? This
> should solve this topic by fixing the lookup in the grid-mapfile.
>
>
>
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
------- Comment #13 From 2007-10-30 03:15:00 -------
Hi Martin, Mike, Gabriel!

I installed Mikes patch on our node udo-gt01.grid.uni-dortmund.de:
did a gpt-build $PATCH;gpt-postinstall; restart container. The sudoers still
contain the globus-gridmap-and-execute stuff. Do I need to remove it, to make
the patch work?

We achieved after patching the same behaviour as before. Jobs without staging
seem to work, but when data is staged we get:


==== Jobs without "-s" Command line option to globusrun-ws ====
freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_dt.xml
Submitting job...Done.
Job ID: uuid:17c1acfc-86c8-11dc-80b1-0050560bd129
Termination time: 10/31/2007 09:11 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp
Current job state: Done
Destroying job...Done.


freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_hp.xml
Submitting job...Done.
Job ID: uuid:1e9c33b2-86c8-11dc-8c42-0050560bd129
Termination time: 10/31/2007 09:11 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp
Current job state: Done
Destroying job...Done



==== Same Jobs as above with "-s" Command line option to globusrun-ws ====
freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_hp.xml -s
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:041cb624-86c8-11dc-9ba1-0050560bd129
Termination time: 10/31/2007 09:10 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
/home/hp0007
Current job state: CleanUp
Current job state: Done
Destroying job...Done.
Cleaning up any delegated credentials...Done.


freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_dt.xml -s
Delegating user credentials...Done.
Submitting job...Done.
Job ID: uuid:0e4e7970-86c8-11dc-b851-0050560bd129
Termination time: 10/31/2007 09:11 GMT
Current job state: Pending
Current job state: Active
Current job state: CleanUp-Hold
globusrun-ws: ignoring error while streaming
gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout:
globus_ftp_client: the server responded with an error
500 500-Command failed. : globus_l_gfs_file_open failed.
500-globus_xio: Unable to open file
/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout
500-globus_xio: System error in open: Permission denied
500-globus_xio: A system call failed: Permission denied
500 End.

globusrun-ws: ignoring error while streaming
gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stderr:
[globus_ftp_control]:globus_ftp_control_data_connect_read():transfer handle
does not exist
Current job state: CleanUp
Current job state: Failed
Destroying job...Done.
Cleaning up any delegated credentials...Done.


In my opinion there is maybe another point where we habe to tweak. I will look
around in the source code if I can find a hint.

Cheer
Stefan
------- Comment #14 From 2007-10-30 03:35:19 -------
I applied the patch, and I verified that libglobus_gss_assist_gcc* 
got updated. 

However, globus-gridmap-and-execute still does not detect 
a local account other than the first one listed in 
the grid-mapfile.

I verified this by running sudo by hand:

  $ sudo -u lrz015ab  
      /lrz/sys/globus/libexec/globus-gridmap-and-execute   
     -g /etc/grid-security/grid-mapfile   
       /lrz/sys/globus/libexec/globus-job-manager-script.pl job.jms

   lrz015ab is not in the grid mapfile

which is an error because lrz015ab is in the grid mapfile

 $ grep Mateescu /etc/grid-security/grid-mapfile 
  "/C=DE/O=GridGermany/OU=Leibniz-Rechenzentrum/OU=HLS/CN=Gabriel Mateescu" 
   a2815ab,lrz015ab

I noticed that globus-gridmap-and-execute is not dynamically linked 
to libglobus_gss_assist_*


  $ ldd  /lrz/sys/globus/libexec/globus-gridmap-and-execute
        linux-gate.so.1 =>  (0xa000000000000000)
        libdl.so.2 => /lib/libdl.so.2 (0x2000000000064000)
        libc.so.6.1 => /lib/libc.so.6.1 (0x200000000007c000)
        /lib/ld-linux-ia64.so.2 (0x2000000000000000)

So perhaps the file gridmap.c needs to be patched also, in addition to 
libglobus_gss_assist.



(In reply to comment #9)
> This package should fix the problem:
> http://www-unix.mcs.anl.gov/~mlink/bugs/globus_gss_assist-3.24.tar.gz
> 
> Use the update installation instructions at
> http://www.globus.org/toolkit/advisories.html
> 
> Let me know how that works for you.
> 
------- Comment #15 From 2007-10-30 04:43:11 -------
I think this is another problem, unrelated to gge.

WS-GRAM should pass localUserId to RFT. 
And RFT should be able to use the syntax 

   gsitp://localUserId@HOST/....

i.e., to prepend localUserId. 

Gabriel.


(In reply to comment #13)
> Hi Martin, Mike, Gabriel!
> 
> I installed Mikes patch on our node udo-gt01.grid.uni-dortmund.de:
> did a gpt-build $PATCH;gpt-postinstall; restart container. The sudoers still
> contain the globus-gridmap-and-execute stuff. Do I need to remove it, to make
> the patch work?



> freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
> udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_dt.xml -s
> Delegating user credentials...Done.
> Submitting job...Done.
> Job ID: uuid:0e4e7970-86c8-11dc-b851-0050560bd129
> Termination time: 10/31/2007 09:11 GMT
> Current job state: Pending
> Current job state: Active
> Current job state: CleanUp-Hold
> globusrun-ws: ignoring error while streaming
> gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout:
> globus_ftp_client: the server responded with an error
> 500 500-Command failed. : globus_l_gfs_file_open failed.
> 500-globus_xio: Unable to open file
> /home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout
> 500-globus_xio: System error in open: Permission denied
> 500-globus_xio: A system call failed: Permission denied
> 500 End.
> 
> globusrun-ws: ignoring error while streaming
> gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stderr:
> [globus_ftp_control]:globus_ftp_control_data_connect_read():transfer handle
> does not exist
> Current job state: CleanUp
> Current job state: Failed
> Destroying job...Done.
> Cleaning up any delegated credentials...Done.
> 
> 
> In my opinion there is maybe another point where we habe to tweak. I will look
> around in the source code if I can find a hint.
> 
> Cheer
> Stefan
> 
------- Comment #16 From 2007-10-30 05:00:33 -------
Hi Gabriel,

I think you are right. 
It looks to me that when the "-s" option is specified for globusrun-ws the
gsiftp connection does not use the correct user:

== short snippet from jobsubmission ==
gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/9e3cb8ac-86d3-11dc-932e-0050560bd129.0.stdout:
230 User hp0007 logged in.
== short snippet from jobsubmission ==

I submitted a job for the local user dt0031 (one of my local accounts) and
another of my local accounts (hp0007) was used for the gsiftp connection to
display stdout, stderr on my "user interface". This was the reason displaying
later on messages like

500-Command failed. : globus_l_gfs_file_open failed.
500-globus_xio: Unable to open file
/home/dt0031/9e3cb8ac-86d3-11dc-932e-0050560bd129.0.stdout
500-globus_xio: System error in open: Permission denied
500-globus_xio: A system call failed: Permission denied

Does anyone know how the username is forwarded from gram to rft?

Cheers
Stefan

(In reply to comment #15)
> I think this is another problem, unrelated to gge.
> 
> WS-GRAM should pass localUserId to RFT. 
> And RFT should be able to use the syntax 
> 
>    gsitp://localUserId@HOST/....
> 
> i.e., to prepend localUserId. 
> 
> Gabriel.
> 
> 
> (In reply to comment #13)
> > Hi Martin, Mike, Gabriel!
> > 
> > I installed Mikes patch on our node udo-gt01.grid.uni-dortmund.de:
> > did a gpt-build $PATCH;gpt-postinstall; restart container. The sudoers still
> > contain the globus-gridmap-and-execute stuff. Do I need to remove it, to make
> > the patch work?
> 
> 
> 
> > freitag@udo-gt01:~/jobs/xml/whoami> globusrun-ws  -submit -F
> > udo-gt01.grid.uni-dortmund.de -Ft PBS  -f whoami_dt.xml -s
> > Delegating user credentials...Done.
> > Submitting job...Done.
> > Job ID: uuid:0e4e7970-86c8-11dc-b851-0050560bd129
> > Termination time: 10/31/2007 09:11 GMT
> > Current job state: Pending
> > Current job state: Active
> > Current job state: CleanUp-Hold
> > globusrun-ws: ignoring error while streaming
> > gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout:
> > globus_ftp_client: the server responded with an error
> > 500 500-Command failed. : globus_l_gfs_file_open failed.
> > 500-globus_xio: Unable to open file
> > /home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stdout
> > 500-globus_xio: System error in open: Permission denied
> > 500-globus_xio: A system call failed: Permission denied
> > 500 End.
> > 
> > globusrun-ws: ignoring error while streaming
> > gsiftp://udo-gt01.grid.uni-dortmund.de:2811/home/dt0031/0e4e7970-86c8-11dc-b851-0050560bd129.0.stderr:
> > [globus_ftp_control]:globus_ftp_control_data_connect_read():transfer handle
> > does not exist
> > Current job state: CleanUp
> > Current job state: Failed
> > Destroying job...Done.
> > Cleaning up any delegated credentials...Done.
> > 
> > 
> > In my opinion there is maybe another point where we habe to tweak. I will look
> > around in the source code if I can find a hint.
> > 
> > Cheer
> > Stefan
> > 
> 
------- Comment #17 From 2007-10-30 08:19:16 -------
Hi Gabriel and Stefan,

I agree that GRAM should pass the local user id along to RFT as described in
comment 15.  This is something we would like to do, but we cannot work on this
right now.  We would welcome and review a patch if you are able to get it
before us.

thanks,
Stu
------- Comment #18 From 2007-10-30 09:44:27 -------
I suggest that we stick to globus-gridmap-and-execute in this bug.

There seem to be two related topics that prevent from proper usage
of local user ids:

* A local user id specified in a gram job seems not to be used
  by globusrun-ws when it uses gridftp to stream output.
* Passing a local user id as part of a url (gsiftp://user@host/path)
  to RFT does not seem to have an effect.

Both items will be verified and if needed resolved in different bugs.
Once we verified those things the D-GRID guys are added on CC on these
bugs.
------- Comment #19 From 2007-10-30 11:30:04 -------
Subject: Re:  Misbehaviour of globus-gridmap-and-execute

On 10/30/07, bugzilla-daemon@mcs.anl.gov <bugzilla-daemon@mcs.anl.gov> wrote:
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=5457
>
> ------- Comment #18 from feller@mcs.anl.gov  2007-10-30 09:44 -------
> I suggest that we stick to globus-gridmap-and-execute in this bug.
>
> There seem to be two related topics that prevent from proper usage
> of local user ids:
>
> * A local user id specified in a gram job seems not to be used
>   by globusrun-ws when it uses gridftp to stream output.


I agree. We can stick to this problem in this bug, and leave
the item below for later.


> * Passing a local user id as part of a url (gsiftp://user@host/path)
>   to RFT does not seem to have an effect.
>
> Both items will be verified and if needed resolved in different bugs.
> Once we verified those things the D-GRID guys are added on CC on these
> bugs.
>
------- Comment #20 From 2007-10-30 11:40:04 -------
Subject: Re:  Misbehaviour of globus-gridmap-and-execute

Yes. We can limit this bug to fixing the problem in
globus-gridmap-and-execute.

But the patch provided so far seems to fix a problem
in libglobus_gss_assist_*  but not in
globus-gridmap-and-execute (which is not linked
to libglobus_gss_assist_*).



On 10/30/07, bugzilla-daemon@mcs.anl.gov <bugzilla-daemon@mcs.anl.gov> wrote:
> http://bugzilla.globus.org/bugzilla/show_bug.cgi?id=5457
>
>
> smartin@mcs.anl.gov changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>          AssignedTo|smartin@mcs.anl.gov         |feller@mcs.anl.gov
>
>
>
>
> ------- Comment #17 from smartin@mcs.anl.gov  2007-10-30 08:19 -------
> Hi Gabriel and Stefan,
>
> I agree that GRAM should pass the local user id along to RFT as described in
> comment 15.  This is something we would like to do, but we cannot work on this
> right now.  We would welcome and review a patch if you are able to get it
> before us.
>
> thanks,
> Stu
>
>
>
>
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug, or are watching someone who is.
>
------- Comment #21 From 2007-10-30 14:46:43 -------
(In reply to comment #14)
> I applied the patch, and I verified that libglobus_gss_assist_gcc* 
> got updated. 
> 
> However, globus-gridmap-and-execute still does not detect 
> a local account other than the first one listed in 
> the grid-mapfile.


It looks like globus-gridmap-and-execute is built with all of the globus
libraries statically linked in to avoid problems using it under sudo.  If you
still have the installer around, you can run (one line):
gpt-build -force -static
-srcdir=[installerpath]/source-trees/ws-gram/service/gridmap_and_execute/source
 [flavor]

Otherwise, I will be making some changes to that package as well soon and they
will both be listed on the advisories page.
------- Comment #22 From 2007-10-31 06:00:54 -------
I confirm that doing a force-rebuild of globus-gridmap-and-execute 
solves the problem of using a local account which is not the 
first one listed in the grid-mapfile. 

So from my standpoint, the gge problem is solved, and I think 
that Martin has presented a very good analysis of the GridFTP 
and globusrn-ws issues that will be addressed elsewhere.


(In reply to comment #21)
> (In reply to comment #14)
> > I applied the patch, and I verified that libglobus_gss_assist_gcc* 
> > got updated. 
> > 
> > However, globus-gridmap-and-execute still does not detect 
> > a local account other than the first one listed in 
> > the grid-mapfile.
> 
> 
> It looks like globus-gridmap-and-execute is built with all of the globus
> libraries statically linked in to avoid problems using it under sudo.  If you
> still have the installer around, you can run (one line):
> gpt-build -force -static
> -srcdir=[installerpath]/source-trees/ws-gram/service/gridmap_and_execute/source
>  [flavor]
> 
> Otherwise, I will be making some changes to that package as well soon and they
> will both be listed on the advisories page.
> 
------- Comment #23 From 2007-11-29 23:39:16 -------
Mike fixed that. We should get it into the 4.0 branch
and into trunk for 4.2
------- Comment #24 From 2007-12-06 14:58:10 -------
It had already been in 4.0.x branch, committed to trunk and added to 

http://www.globus.org/toolkit/advisories.html