[gin-auth] [gin-ops] Debugging Globus SSL (Was: Re: start Savannah run)

David Bannon D.Bannon at vpac.org
Tue Feb 6 04:23:15 CST 2007


Our approach here in the APACGrid is to map each VO to a single user,
via GUMS and VOMRS. And that user has the associated quota and
permissions as appropriate.

We'd quite like to use pooled accounts, where the "run time user" is
assigned at run time and not reused simultaneously. But I have not seen
that working yet....

So, we'd have trouble mapping our GIN accounts to anything other than
one virtual user unless we break the VO up. And like Oscar said,
everyone having a dedicated account is just not on !

But I'd also agree with Oscar about not assuming any consistancy, for
example, between jobs. That would be very silly indeed!

David




On Tue, 2007-02-06 at 09:22 +0100, Oscar Koeroo wrote:
> Hi JP,
> 
> I would say that creating a bunch of anonymous accounts would be a more 
> real-world and scalable scenario. We're now a group with a limited 
> number of people but I think it would be flawed to give everybody a 
> fixed account.
> 
> For instance in the LCG/EGEE production facilities there is one thing 
> you can be very certain about and that is that your account is an 
> anonymous poolaccount, it is mapped to your DN (and offered VOMS 
> attributes). This mapping is sticky but it can be scratched and cleaned 
> at any given time.
> 
> The bottom line is that you shouldn't rely on any consistency regarding 
> the effective Unix account that you may be using on a cluster.
> 
> This is not a matter of security, it is a matter of scale.
> 
> 
> 	Oscar
> 
> 
> 
> 
> JP Navarro wrote:
> > On Feb 5, 2007, at 5:00 AM, Mike 'Mike' Jones wrote:
> >> By the way, mapping all users to one account is a serious security  
> >> flaw.
> > 
> > Mike,
> > 
> > You are very correct.  My understanding is that mapping all GIN users to
> > a single account was a temporary approach to get GIN off the ground. It
> > certainly wasn't intended to be a long-term solution, or to be used for
> > more than proof-of-interoperability demos.
> > 
> > Perhaps it is now time to come up with a more secure long term solution
> > for GIN participants.  Since there are only a few GIN users today,  
> > should
> > we create individual accounts for all GIN users on all GIN participating
> > grids?  Or is there a better option that will scale better? Any  
> > suggestions
> > on what that next, more secure, approach should be?
> > 
> > Regards,
> > 
> > JP
> > ------------------------------------------------------------------------ 
> > ------
> > John-Paul Navarro                                               (630)  
> > 252-1233
> > navarro at mcs.anl.gov                            http://www.mcs.anl.gov/ 
> > ~navarro
> > TeraGrid Software Integration                Univ of Chicago/Argonne  
> > Nat. Lab.
> > GPG: 4EA9 C86B C0F0 113D 6306  98B7 3649 D6CB EFA8 4133
> > 
> > 
> > 
> > 
> > 
> > 
> > 
> > --
> >   gin-ops mailing list
> >   gin-ops at ogf.org
> >   http://www.ogf.org/mailman/listinfo/gin-ops
> --
>   gin-auth mailing list
>   gin-auth at ogf.org
>   http://www.ogf.org/mailman/listinfo/gin-auth


More information about the gin-auth mailing list