Bug 4718 - Command filtering in globus-job-manager-script
: Command filtering in globus-job-manager-script
: unspecified
: All All
: P2 enhancement
: ---
Assigned To:
: 6192
  Show dependency treegraph
Reported: 2006-09-20 10:06 by
Modified: 2008-08-15 06:24 (History)

Diff file for globus-job-manager-script.in (836 bytes, patch)
2006-09-20 10:08, Kevin Price
more robudy diff file for globus-job-manager-script.pl (1.18 KB, patch)
2006-09-20 13:38, Kevin Price
Updated patch to address any injection concerns (1.23 KB, patch)
2006-10-04 13:31, Kevin Price


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

Description From 2006-09-20 10:06:49
This is a simple enhancement to globus-job-manager-script.pl that allows a
system administrator to have GRAM pass new job requests through a filter before
executing them. The filter decides if the job is allowed or not, based on the
job executable and arguments and on the current user. A return value of '0'
indicates an allowed command, and a non-'0' return value indicates a denied

Attached is a patch file that can be applied to
or directly to

The filter command is set as a variable at the top of the script. By default it
is commented out, which indicates no filtering. (The default string given is
for the commsh application that we're hoping to use this with initially.)
------- Comment #1 From 2006-09-20 10:08:32 -------
Created an attachment (id=1051) [details]
Diff file for globus-job-manager-script.in

Should work on either globus-job-manager-script.in pre-install or on
globus-job-manager-script.pl post-install. Diff is against the 4.0.3 version of
------- Comment #2 From 2006-09-20 10:31:22 -------
This looks cool, thanks. For now we can't commit this to the globus_4_0_branch
code since our current policy is to commit only bug fixes there. That may
change, but for now that's the way it is. So it'd be great if you could also
come up with a patch for the code in HEAD.

I'd recommdend doing it slightly differently, though. In HEAD the Java adapter
interface has been separated out and made more generic. In the interface there
is a preSubmit method that you could use to run an "authorize" command (would
need to be added) in the perl adapter.

You could then add a configuration option to the adapter setup script
specifying the authorization Perl module to use (via automake substitutions of
the .in file). Lastly, this would allow you to provide a GPT package with your
particular authorization Perl module, making the entire mechanism much more

If you get stuck, feel free to discuss this on gram-dev since this is a
development discussion.
------- Comment #3 From 2006-09-20 13:38:52 -------
Created an attachment (id=1052) [details]
more robudy diff file for globus-job-manager-script.pl

This is a more robust diff file designed to be used with patch -p0. It modifies
the globus-job-manager-script.pl file. It is based off the current CVS HEAD
version of the file, but it will also correctly patch the 4.0.3 (and probably
other) versions.

This is not a change to the solution, just a better patch file.
------- Comment #4 From 2006-10-04 12:54:26 -------
Alain Roy pointed out to me that it looks like this is subject to user injected
badness.  We're running a system() command based on the user's RSL-input
executable and arguments.  Could the user be using characters like pipes and
semicolons in RSL arguments to trick the filter command into saying "yes" when
it shouldn't?
------- Comment #5 From 2006-10-04 13:05:26 -------
I agree. The system() call should be passed an array of arguments to prevent
shell processing of the arguments.
------- Comment #6 From 2006-10-04 13:09:36 -------
Until we either have an updated patch that is free of injection badness, or
we're convinced that there isn't injection badness, I recommend that neither
TeraGrid or VDT use this patch. 
------- Comment #7 From 2006-10-04 13:31:18 -------
Created an attachment (id=1067) [details]
Updated patch to address any injection concerns

This patch passes arguments to system() via a list, which prevents perl from
using a shell to interpret the parameters.
------- Comment #8 From 2006-10-04 13:34:41 -------
I'm not convinced this was a problem, as the (old) patch escaped any quotation
marks in the command string before passing it to the filter.  Still, Von's
suggestion of using perl's system() call in list format guarantees that the
shell hasn't interpreted any special characters.

The drawback to this approach is that the filter command has to be spliced into
chunks, but I can't see this being a problem in most (if any) cases.
------- Comment #9 From 2006-10-16 10:07:23 -------
Alain - have you had a chance to evaluate the revamped patch? Does it address
your concerns?
------- Comment #10 From 2006-10-17 21:45:02 -------
Subject: Re:  Command filtering in globus-job-manager-script

>Alain - have you had a chance to evaluate the revamped patch? Does it address
>your concerns?

Yes, it addresses my security concerns.

I'm not convinced that it's useful by itself. The exercise of writing 
a filter that works well has been left to the reader, and it seems 
difficult to do correctly. That said, I don't object.

------- Comment #11 From 2006-10-19 14:57:59 -------

Please apply this patch to both the 4 0 branch and the trunk.

------- Comment #12 From 2007-11-20 15:25:47 -------
Has this patch been applied?  We're using it in TG to restrict community
accounts via the community shell
------- Comment #13 From 2008-02-05 14:58:31 -------
Moving this to the LRMA project
------- Comment #14 From 2008-08-15 06:24:06 -------
Committed to 4.2 branch and trunk.