[torqueusers] Security Vulnerability in Torque

[Garrick Staples]

On Sat, Oct 21, 2006 at 01:23:06AM +0100, David Golden alleged:
> On 2006-10-20 17:51:04 -0600, Garrick Staples wrote:
> 
> > > re style of fix:
> > > 
> > > * I guess one part of the fix might be to sete[ug]id before open
> > > even in the keeping=0 case... I don't see why one wouldn't? (except of 
> > > course on systems that don't support sete[ug]id at all...). Does
> > > that in fact eliminate any problem?
> > 
> > This does exactly that:
> > http://www.clusterresources.com/pipermail/torquedev/2006-October/000344.html
> > 
> 
> ...oops... I really should subscribe to -dev...
> 
> One thought - O_EXCL, while a good idea to include, is traditionally still
> not necessarily safe on e.g. NFS.   Now, not sure it's all that likely that 
> /var/spool/pbs/spool will be on NFS, but I can imagine e.g. newly
> sharedroot/diskless/warewulf systems where the admin doesn't initially
> realise that it makes relatively little sense to keep spooling... 
> because (er) I didn't when I moved to shared root...

But even with NFS, each node would still have a unique spool dir, so
O_EXCL gets us the same safety.

At any rate, it isn't any worse :)

 
> > I'm divided on removing the malicious link on the fly.  On the one hand,
> > we want to raise a giant red flag to alert the admin.  On the other
> > hand, we don't want a malicious user to break other users' job.
> > 
> 
> Have per-user subdirectories under pbs/spool/ in the non-disable-spool 
> case? But... then be careful when creating _them_...

Which is relatively safe since mkdir(2) doesn't follow symlinks, but it
would break 3rd party stuff.  Maybe in 2.2...

-- 
Garrick Staples, Linux/HPCC Administrator
University of Southern California
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torqueusers/attachments/20061020/d40f1082/attachment-0001.bin