On Wed, 2005-10-19 at 10:42 -0400, Jason A. Smith wrote:
> On Wed, 2005-10-19 at 07:42 +0200, Åke Sandgren wrote:
> > On Tue, 2005-10-18 at 14:23 +0200, Oscar Koeroo wrote:
> > > Hi Maarten:
> > > From a security point of view I can understand this very strict use of
> > > giving each job its own poolaccount.
> >
> > I for one can't think a anything at all that would increase security by
> > having one account / job. Examples please?
>
> What would be your alternative, a group account for each VO? For
> security purposes, you want to be able to audit the users actions on
> your site and for this to be possible you have to give each user their
> own local account. In fact, recycling pool accounts makes this a little
> harder since you now have to keep a complete history of when each user
> was mapped to each pool account.
I wasn't suggesting to stop using one account / DN just that i couldn't
see any use for one account / job.
And having one account / job just gives you a bigger list of mappings to
keep track of (for a long time too since such lists should be kept for
at least a year or more)
> > On the contrary having one account / job increases complexity and hence
> > increases the risk for security problems.
>
> I don't see how a pool of accounts causes a major increase in complexity
> if a facility goes from say hundreds of local user accounts to 10s of
> thousands of grid pool accounts. Each unused pool account only takes up
> negligible space in your passwd/nis/ldap (or whatever account system
> your facility uses) area and negligible space for an empty directory on
> your /home disk.
It's not pool accounts per se that is causing the increased complexity,
but having one poolaccount / job compared to one poolaccount/DN.
And large sites would have to deal with multiple 100k's of accounts.
|