Awesome. Thanks Vinod. Let me try that. On Fri, Mar 6, 2015 at 10:08 PM, Vinod Kone <[email protected]> wrote:
> Quoting form the documentation > <http://mesos.apache.org/documentation/latest/authorization/>: > > " > > There are couple of important things to note: > > 1. > > ACLs are matched in the order that they are setup. In other words, the > first matching ACL determines whether a request is authorized or not. > 2. > > If none of the specified ACLs match the given request, whether the > request is authorized or not is defined by ACLs.permissive field. By > default this is “true” i.e., a non-matching request is authorized. > > > " > > So in your case, since the user doesn't match "user1" and "permissive" is > not set (default), the request is authorized. > > If you only want your framework to run tasks as "user1", add '"permissive" > = false' to your ACLs JSON. > > HTH, > > > On Fri, Mar 6, 2015 at 2:32 AM, Sivaram Kannan <[email protected]> > wrote: > >> >> Just to make it more clear, I want to understand in which scenario would >> the task authorization will fail and framework gets a TASK_LOST error. I >> would greatly appreciate If you could give an example what I should change >> in the acl.json and the master or slave to get the TASK_LOST errror. >> >> Version of Mesos: 0.21.1 and marathon v0.7.7-SNAPSHOT. All of them are >> being run as docker containers. >> >> Thanks, >> ./Siva. >> >> On Fri, Mar 6, 2015 at 2:36 PM, Sivaram Kannan <[email protected]> >> wrote: >> >>> >>> Guess I don't understand then. Let me give some tests I ran for >>> understanding ACL, but am not clear which unix users is this. Assume I have >>> two nodes. >>> >>> Node1 - runs Mesos-master and marathon >>> Node2 - runs mesos-slave >>> >>> Both the above nodes have an users named devel and root. >>> >>> Test1: I started the mesos-master with the following acl.json >>> >>> "run_tasks": [ >>> { >>> "principals": { >>> "values": [ >>> "marathon" >>> ] >>> }, >>> "users": { >>> "values": [ >>> "root", >>> "devel" >>> ] >>> } >>> }, >>> { >>> "principals": { >>> "values": [ >>> "marathon" >>> ] >>> }, >>> "users": { >>> "type": "NONE" >>> } >>> } >>> ] >>> >>> I was able to launch the tasks from the marathon. Now I modified the >>> acl.json as follow and relaunched the mesos-master. In this I wanted to >>> make the task fail and see the error >>> >>> "principals": { >>> "values": [ >>> "marathon" >>> ] >>> }, >>> "users": { >>> "values": [ >>> "user1" >>> ] >>> } >>> >>> >>> Even now I am able to launch the tasks from the marathon instance. So, >>> can you please tell me which nodes unix user does values under "users" tag >>> refers to? Am I making anything wrong in the way I am using run_tasks?? >>> >>> Thanks, >>> ./Siva >>> >>> On Thu, Mar 5, 2015 at 11:35 PM, Vinod Kone <[email protected]> >>> wrote: >>> >>>> I'm not very familiar with Marathon, but the 'user' in the 'run_tasks' >>>> ACL is the unix user that the executor/run process runs as. This user is >>>> set by frameworks by setting 'CommandInfo.user'. >>>> >>>> On Thu, Mar 5, 2015 at 9:06 AM, Sivaram Kannan <[email protected]> >>>> wrote: >>>> >>>>> >>>>> Hi, >>>>> >>>>> The user that is defined as part of Mesos's Authorization ACL, which >>>>> user is it? Taking marathon framework as example, the users defined as >>>>> part >>>>> of run_tasks principal, is it the user that is used to run marathon >>>>> executable or the unix user available in the mesos-slave's? >>>>> >>>>> Documentation in >>>>> http://mesos.apache.org/documentation/latest/authorization/ does not >>>>> seems to be clear on that. Can someone clarify? >>>>> >>>>> Thanks, >>>>> ./Siva. >>>>> >>>>> >>>> >>> >>> >>> -- >>> ever tried. ever failed. no matter. >>> try again. fail again. fail better. >>> -- Samuel Beckett >>> >> >> >> >> -- >> ever tried. ever failed. no matter. >> try again. fail again. fail better. >> -- Samuel Beckett >> > > -- ever tried. ever failed. no matter. try again. fail again. fail better. -- Samuel Beckett
