[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.
[ My primary concern is unintended information leakage between two
different DNs as a result of an incomplete pool account reset. My
secondary concern is pool account home directories and other areas
becoming completely full, rendering that pool account or host unusable.]
> 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.
Cheers,
David
--
David McBride <[log in to unmask]>
Department of Computing, Imperial College, London
|