Quantcast

Proposal: Batch Job Visibility Restrictions

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Proposal: Batch Job Visibility Restrictions

James Perkins
Currently a deployment can view, stop, restart or abandon any batch job that has been submitted or has been executed that exists in the job repository. This includes batch jobs from other deployments if the job repository is shared, which is the default. I cannot however start a batch job from another deployment.

I'm proposing we limit visibility so that a deployment can only access jobs which belong to that deployment.

I'd like to get some opinions on this. 

There are some, possibly unacceptable, repercussions. For example if a user has a deployment that displays information about batch jobs for all deployments this change would break that. However it does seem wrong to allow any deployment using a shared repository to stop, start or abandon a job from a different deployment. 

One, probably more complicated, option would be to have an attribute on the job-repository to allow jobs to be visible to any deployment with access to the job-repository.

--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Batch Job Visibility Restrictions

David M. Lloyd
I think this is a smart idea.  I must ask though, why can I not start a
batch job from another deployment?  Is it just a design limitation?

Usually we'd want to restrict access to things not by deployment (which
is a somewhat fluid concept) but by identity and authorization permissions.

On 12/02/2016 07:09 PM, James Perkins wrote:

> Currently a deployment can view, stop, restart or abandon any batch job
> that has been submitted or has been executed that exists in the job
> repository. This includes batch jobs from other deployments if the job
> repository is shared, which is the default. I cannot however start a
> batch job from another deployment.
>
> I'm proposing we limit visibility so that a deployment can only access
> jobs which belong to that deployment.
>
> I'd like to get some opinions on this.
>
> There are some, possibly unacceptable, repercussions. For example if a
> user has a deployment that displays information about batch jobs for all
> deployments this change would break that. However it does seem wrong to
> allow any deployment using a shared repository to stop, start or abandon
> a job from a different deployment.
>
> One, probably more complicated, option would be to have an attribute on
> the job-repository to allow jobs to be visible to any deployment with
> access to the job-repository.
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Proposal: Batch Job Visibility Restrictions

James Perkins


On Sat, Dec 3, 2016 at 1:22 PM, David M. Lloyd <[hidden email]> wrote:
I think this is a smart idea.  I must ask though, why can I not start a
batch job from another deployment?  Is it just a design limitation?

To start a job you need access to the job XML file and the CDI beans for the deployment. However there is no limitation on the other operations.
 

Usually we'd want to restrict access to things not by deployment (which
is a somewhat fluid concept) but by identity and authorization permissions.

I'm going to be adding permissions too for each operation. My plan was to have a start, stop, restart, abandon and read permission for each operation. This proposal is more just not allowing A.war to stop a job from B.war if the two deployments are not setup as dependent on each other.
 

On 12/02/2016 07:09 PM, James Perkins wrote:
> Currently a deployment can view, stop, restart or abandon any batch job
> that has been submitted or has been executed that exists in the job
> repository. This includes batch jobs from other deployments if the job
> repository is shared, which is the default. I cannot however start a
> batch job from another deployment.
>
> I'm proposing we limit visibility so that a deployment can only access
> jobs which belong to that deployment.
>
> I'd like to get some opinions on this.
>
> There are some, possibly unacceptable, repercussions. For example if a
> user has a deployment that displays information about batch jobs for all
> deployments this change would break that. However it does seem wrong to
> allow any deployment using a shared repository to stop, start or abandon
> a job from a different deployment.
>
> One, probably more complicated, option would be to have an attribute on
> the job-repository to allow jobs to be visible to any deployment with
> access to the job-repository.
>
> --
> James R. Perkins
> JBoss by Red Hat
>
>
> _______________________________________________
> wildfly-dev mailing list
> [hidden email]
> https://lists.jboss.org/mailman/listinfo/wildfly-dev
>

--
- DML
_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev



--
James R. Perkins
JBoss by Red Hat

_______________________________________________
wildfly-dev mailing list
[hidden email]
https://lists.jboss.org/mailman/listinfo/wildfly-dev
Loading...