[torqueusers] Security Vulnerability in Torque
garrick at usc.edu
Fri Oct 20 18:31:32 MDT 2006
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
Size: 189 bytes
Desc: not available
Url : http://www.supercluster.org/pipermail/torqueusers/attachments/20061020/d40f1082/attachment-0001.bin
More information about the torqueusers