Testbed Support for GridPP member institutes
> [mailto:[log in to unmask]] On Behalf Of Dr D J Colling said:
> This is the
> first one that he has done this for. This clearly is a very serious
> problem as it removes the definite mapping between a user
> running a job and the real person, so breaking the security policy at
This is conceptually much the same as using cron jobs or ssh to a
different WN, or indeed running jobs on the CE with the fork jobmanager.
The security impact depends on the general question of how pool accounts
are recycled. I don't know what actually happens, but what should happen
is that the account is completely wiped, i.e. any running processes and
any files owned by that user are removed. The information about who is
mapped to which account when should of course be preserved. If that's
done then these things don't have a major security implication, although
they do of course impact on accounting.
In general it would probably be worthwhile for sites to monitor the
processes running on WNs and CEs to look for any which are not
associated with batch jobs, and perhaps check the total cpu time used by
user processes to compare with accounting records. Similarly there is
probably no good reason for any persistent files to be stored in the
home directories or elsewhere, so that could also be monitored
(obviously proxies in particular should not stay around after the end of
> Steve T. says this is a serious problem however I don't see
> any activity correcting it.
I'm not entirely sure it's possible to correct it, is it possible to
identify all processes forked from a specific process even if they
change the PPID and PGID? However, I agree with the general point, I
don't see anyone trying to identify holes and plug them systematically.
PS I've attached a couple of recent mails in the security mailing list
with some bearing on this ...