mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Michael Park" <mcyp...@gmail.com>
Subject Re: Review Request 39988: [4/5] Added authorization for dynamic reservation master endpoints.
Date Tue, 01 Dec 2015 15:57:19 GMT

-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39988/#review108510
-----------------------------------------------------------



src/master/http.cpp (lines 1037 - 1040)
<https://reviews.apache.org/r/39988/#comment167962>

    Let's not lose the comment on the left.



src/master/http.cpp (lines 1037 - 1041)
<https://reviews.apache.org/r/39988/#comment167963>

    It looks like the `repair` here is to catch the case where `authorizeReserveResources`
__fails__ on an invalid reserve request.
    
    In https://reviews.apache.org/r/39987/ I asked whether the validation step needs to be
within the authorization step. I still think it should be separated. If we were to separate
them out, with Jie's suggestion below in mind, this could look like:
    
    ```cpp
      return master->authorizeReserveResources(operation, principal)
        .then(defer(master->self(), [=](bool authorized) -> Future<Response> {
          if (!authorized) {
            return Unauthorized("Mesos master");
          }
          Option<Error> error =
            validation::operation::validate(operation.reserve(), None(), principal);
          if (error.isSome()) {
            return BadRequest("Invalid RESERVE operation: " + error.get().message);
          }
          return _operation(slaveId, resources.flatten(), operation);
        }));
    ```



src/master/http.cpp (lines 2307 - 2317)
<https://reviews.apache.org/r/39988/#comment167965>

    With Jie's suggestion, we don't need this anymore. However, I would like to point out
some weirdness here for future reference.
    
    Since the `_operation` is only being used with `.then` or in a direct call, the `authorized`
can/should be `bool` rather than `Future<bool>`. Take a look at `_teardown`. The reason
this works as-is is because `bool` is implicitly convertible to `Future<bool>`.
    
    With that in mind, we can then observe that the `if (!authorized.isReady())` is actually
dead code. Whatever error handling that was intended to be done in that if-clause actually
gets caught by the `repair` above instead.


- Michael Park


On Nov. 30, 2015, 8:46 p.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39988/
> -----------------------------------------------------------
> 
> (Updated Nov. 30, 2015, 8:46 p.m.)
> 
> 
> Review request for mesos, Adam B, Jie Yu, Michael Park, and Till Toenshoff.
> 
> 
> Bugs: MESOS-3062
>     https://issues.apache.org/jira/browse/MESOS-3062
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Added authorization for dynamic reservation master endpoints.
> Note: this review is continued from https://reviews.apache.org/r/37126/
> 
> 
> Diffs
> -----
> 
>   src/master/http.cpp 9d729ef7f7d7ad6185934648f833e4f8a4f0a123 
>   src/master/master.hpp 96951e766de32842197506504e5ac67a2caa3efe 
>   src/tests/reservation_endpoints_tests.cpp f30ff8bc6a3e9773437fa7fd7c8f569b7d7e2d9d

> 
> Diff: https://reviews.apache.org/r/39988/diff/
> 
> 
> Testing
> -------
> 
> This is the fourth in a chain of 5 patches. Added new reservation endpoints tests to
validate authorization of reserve and unreserve operations using ACLs. `make check` was run
to test after all patches were applied.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message