On Sat, 12 Nov 2005, David McBride wrote:

> [log in to unmask] wrote:
> > On Fri, 11 Nov 2005, David McBride wrote:
> > 
> >> Is there currently any mechanism that reset's a pool account's home
> >> directory back to it's default state before reuse?
> > 
> > The job-related
> > subdirectories ~/.globus and ~/.lcgjm and gram_* logfiles are removed
> > when a pool account is recycled, but that will not happen very often
> > (it does now, but in the next release it will be delayed as much as
> > possible for security reasons).
> 
> Ahh, this sounds like what I've been looking for: where is the mechanism 
> that removes stale data from a pool account when it is recycled?  It 
> sounds like I should be able to add my own hooks to this to completely 
> reset $HOME to a ground state.

There is a cron job "lcg-expiregridmapdir".  Currently it runs once a day,
but that will become once an hour.  The sources are here:

http://isscvs.cern.ch:8180/cgi-bin/cvsweb.cgi/lcg-expiregridmapdir/?cvsroot=lcgware

The latest rpm (for the next release) is here:

http://grid-deployment.web.cern.ch/grid-deployment/RpmDir_i386-sl3/lcg/lcg-expiregridmapdir-2.0.0-1.noarch.rpm

Please start from the latest sources and not from the version that came
with LCG-2_6_0, because there were many issues with the old code.

> [ My primary concern is unintended information leakage between two 
> different DNs as a result of an incomplete pool account reset.  My 

I agree it would be best to remake the home directory from a template,
instead of trying to clean up only certain bits and pieces.
Feel free to submit patches once you have got it to work!

> secondary concern is pool account home directories and other areas 
> becoming completely full, rendering that pool account or host unusable.]

For that we need another cron job; I intend to provide a first version for
the next release.

> > The job is "free" to leave any junk in the home directory or /tmp etc.
> > It is hard to clean up those areas in a robust way without the use of
> > a chroot'ed file system subtree for the job to run in: a WN may run two
> > or more concurrent jobs for the same user, so one cannot simply remove
> > all the user's files at the end of the job.
> 
> /tmp isn't much of a worry; it can easily be cleaned up periodically 
> with tmpwatch.
> 
> > In the course of next year we intend to let each job run in its own
> > virtual machine (Xen) with its own file system, and then this issue
> > goes away, as do a few other security concerns.
> 
> Whilst certainly an exciting idea, Xen won't help _us_ a great deal for 
> a while -- we are adapting our existing (non-Xen-capable) GridEngine 
> cluster to interoperate with LCG, rather than installing a new cluster 
> from scratch.

Xen or some other VM will only be used where available, of course.
Ideally the use of a VM would be a batch system implementation detail,
transparent to the middleware.  Anyway, only when the VMs have proven
themselves over time, we would very much recommend sites to deploy them.