Not quite; the broker has to transfer access to the stagers explicitly. If you only transfer ownership of the job then the user can start, monitor and destroy the job, but they can't access the inputs or outputs.
Destroying a job will cause the job service to destroy the inputs and outputs, regardless of whether the user has access to them or not. On Tue, 26 Aug 2008 14:39:04 +0200, dejw wrote: > Hi Thomas, > > thx for replay > > so I understand that: > > if broker creates a job and delegates it to some user, then all stagers > created during the job execution will belong to that user? (not broker) > > Dawid > > Thomas Leonard wrote: >> On Fri, 22 Aug 2008 11:20:09 +0200, dejw wrote: >> >> >>> Hi, >>> Thomas Leonard wrote: >>> >>>> Hi Dawid, >>>> >>>> One way to handle this is to have the broker create the job as itself >>>> and then transfer ownership to the client. Then the broker does not >>>> need any special privileges. >>>> >>>> >>> Could you explain me what do you mean in case of "transfer ownership"? >>> If broker submits the job >>> then broker is the owner of this job in GRIA. And as I understand the >>> broker is able to move the >>> ownership to someone else who is trusted GRIA user? Then all >>> information connected with such job (and all data stagers) will change >>> the ownership to other user (pointed by the broker?). >>> >>> >> Yes, but there are no "trusted" users. The broker can delegate to >> anyone it wants to, by providing their CA certificate and DN. For >> self-signed certificates, the CA is just the user's certificate, of >> course. >> >> To do this, the broker will do: >> >> job = ... // create new job >> job.addPolicyRule(new PolicyRule(theUser, "owner")); >> job.removePolicyRule(new PolicyRule(broker, "owner")); >> >> You can transfer the inputs and outputs in the same way (using the >> "manager" role). This allows you to create jobs where different people >> provide different inputs and receive different outputs. >> >> I will let someone else answer the registry query. >> >> >> >> > <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"> <html> > <head> > <meta content="text/html;charset=ISO-8859-2" > http-equiv="Content-Type"> <title></title> > </head> > <body bgcolor="#ffffff" text="#000000"> Hi Thomas,<br> > <br> > thx for replay<br> > <br> > so I understand that:<br> > <br> > if broker creates a job and delegates it to some user, then all stagers > created during the job execution will belong to that user? (not > broker)<br> <br> > Dawid<br> > <br> > Thomas Leonard wrote: > <blockquote cite="mid:[EMAIL PROTECTED]" type="cite"> > <pre wrap="">On Fri, 22 Aug 2008 11:20:09 +0200, dejw wrote: > > </pre> > <blockquote type="cite"> > <pre wrap="">Hi, > Thomas Leonard wrote: > </pre> > <blockquote type="cite"> > <pre wrap="">Hi Dawid, > > One way to handle this is to have the broker create the job as itself > and then transfer ownership to the client. Then the broker does not need > any special privileges. > > </pre> > </blockquote> > <pre wrap="">Could you explain me what do you mean in case of > "transfer ownership"? > If broker submits the job > then broker is the owner of this job in GRIA. And as I understand the > broker is able to move the > ownership to someone else who is trusted GRIA user? Then all information > connected with such job (and all data stagers) will change the ownership > to other user (pointed by the broker?). > </pre> > </blockquote> > <pre wrap=""><!----> > Yes, but there are no "trusted" users. The broker can delegate to anyone > it wants to, by providing their CA certificate and DN. For self-signed > certificates, the CA is just the user's certificate, of course. > > To do this, the broker will do: > > job = ... // create new job > job.addPolicyRule(new PolicyRule(theUser, "owner")); > job.removePolicyRule(new PolicyRule(broker, "owner")); > > You can transfer the inputs and outputs in the same way (using the > "manager" role). This allows you to create jobs where different people > provide different inputs and receive different outputs. > > I will let someone else answer the registry query. > > > </pre> > </blockquote> > <br> > </body> > </html> > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge Build the coolest Linux based applications with Moblin SDK & > win great prizes Grand prize is a trip for two to an Open Source event > anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ -- Dr Thomas Leonard IT Innovation Centre 2 Venture Road Southampton Hampshire SO16 7NP Tel: +44 0 23 8076 0834 Fax: +44 0 23 8076 0833 mailto:[EMAIL PROTECTED] http://www.it-innovation.soton.ac.uk ------------------------------------------------------------------------- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ _______________________________________________ gria-general mailing list gria-general@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gria-general
