Bugzilla – Bug 4718
Command filtering in globus-job-manager-script
Last modified: 2008-08-15 06:24:06
You need to
before you can comment on or make changes to this bug.
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.)
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
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
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
This is not a change to the solution, just a better patch file.
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
I agree. The system() call should be passed an array of arguments to prevent
shell processing of the arguments.
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.
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.
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.
Alain - have you had a chance to evaluate the revamped patch? Does it address
Subject: Re: Command filtering in globus-job-manager-script
>Alain - have you had a chance to evaluate the revamped patch? Does it address
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.
Please apply this patch to both the 4 0 branch and the trunk.
Has this patch been applied? We're using it in TG to restrict community
accounts via the community shell
Moving this to the LRMA project
Committed to 4.2 branch and trunk.