[gridengine users] qsub -V doesn't set $PATH

Shiel, Adam daniel.shiel at hpe.com
Fri Apr 3 02:54:19 UTC 2020

I finally had a chance to experiment with this some.

I think one basic problem was that I had bash as a login shell. Removing bash from the login shell and specifying "qsub -S /bin/bash ...." passed my local PATH to the remote job.

But when I don't specify "-S /bin/bash" I get the csh login PATH settings. That's our default shell for the queue I'm using. 

This happens even when csh isn't in the login shell list. I find that unexpected.


-----Original Message-----
From: users-bounces at gridengine.org [mailto:users-bounces at gridengine.org] On Behalf Of Hay, William
Sent: Wednesday, January 22, 2020 9:55 AM
To: Skylar Thompson <skylar2 at uw.edu>
Cc: users at gridengine.org
Subject: Re: [gridengine users] qsub -V doesn't set $PATH

On Tue, Jan 21, 2020 at 03:51:01PM +0000, Skylar Thompson wrote:
> -V strips out PATH and LD_LIBRARY_PATH for security reasons, since 
> prolog

I don't think this is the case.  I've just experimented with one of our 8.1.9 clusters and I can set arbitrary PATHs run qsub -V and have the value I set show up in the environment of the job.  More likely the job is being run with a shell that is configured as a login shell and the init scripts for the shell are stomping on the value of PATH.

> and epilog scripts run with the submission environment but possibly in 
> the context of a different user (i.e. a user could point a 
> root-running prolog script at compromised binaries or C library).

This is something slightly different. The prolog and epilog used to run with the exact same environment as the job.  This opened up an attack vector , especially if the prolog or epilog were run as a privileged user rather than the job owner.  The environment in which the prolog and eiplog are run is now sanitised.


More information about the users mailing list