Re: multimple domain authentication

>> unless someone want to code up some 'orribly complex
>> group rights nonsense.
> 
> I should just shut up, and I will.  

please don't.  we're all fishing for ideas here and the more of us do
it the better.

> But I don't intend
> something complex.  I'm just saying (probably poorly)
> that if you're giving some access to users whose names
> aren't previously known to a file server, the file server
> needs to have some notion of those users' rights. 

that's the real pickle we're in -- the user@domain model doesn't play
nicely with write services (it's relatively a non-issue with read-only
ones, but one can think an opposite example pretty quickly -- how do
you create a file readable for rminnich@ucalgary and not readable for
andrey@ucalgary, without knowing that those two users exist -- you
won't know because you have no control over the ucalgary auth domain
and can't see who's a user there; it's an artificial example, but an
example nonetheless)

> So
> you probably need to mess with fossil (and maybe others)
> and think/work out the issues.  I was just thinking of
> having default rights (maybe nothing) for unknown users
> in trusted domains and the ability to override that
> default for specific users/domains, probably by adding
> them to a local group.  I thought about having the AS
> manage group membership and pass those things around,
> but I didn't mean to suggest that -- that probably would
> get "'orribly complex".  It just sounded to me like Andrey
> was saying fossil wouldn't be affected, and Ron was saying
> that the file servers could be ignored because we weren't
> concerned with serving files.  I probably misunderstood.

every service on the grid allowing writes is affected, though i can
see why ron doesn't want fossil mangled in the grid -- give a user's
job its own scratch space (protected in its own private namespace,
solves so many problems with temp files in /scratch for big compute
clusters!) and let them worry about arranging how to move the data off
of there once they've completed their run.

if you decide to provide a grid storage service on the other hand you
will almost invariably end up writing something that has the
capability to control much more than just simple usernames yourself.
things like caching, access policy, storage and bandtwidth limits, etc
-- something fossil isn't well suited for anyway.

> 
> Sorry for the noise,
> 

not noise at all, we're all 'thinking out loud' :)

andrey

ps: inferno's new 'grid workflow management system in a (nut)shell' is
pretty interesting.