You are viewing a plain text version of this content. The canonical link for it is here.
Posted to reviews@mesos.apache.org by Adam B <ad...@mesosphere.io> on 2015/06/01 10:06:13 UTC
Re: Review Request 33295: Added firewall mechanism to control access
on libprocess http endpoints.
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33295/#review85950
-----------------------------------------------------------
Looks very close! Just some minor nits and suggested rewordings, plus a request to better document/test the behavior for inexact matches (substrings/wildcards).
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137769>
FirewallRule shouldn't know what happens when apply() returns false. That's up to the caller. Maybe a future caller wants to redirect instead of reject/403.
Leave this part of the comment in the specific caller or a docs/firewall.md, and just explain what the @return value means from the context of FirewallRule and a generic caller.
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137770>
Again, you're describing the caller's behavior, not this function's behavior and how its results should be interpreted.
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137767>
Please capitalize "The" beginning of each @param description.
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137778>
Why not return a Try? Then the rule has the option of providing an error message, and the caller will read like:
Try<Nothing> applied = rule->apply();
if(applied.isError()) {
LOG << applied.error();
}
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137771>
"Simple firewall rule to reject any connection requesting a path [exactly matchine one] in the provided list of disabled endpoints."
3rdparty/libprocess/include/process/firewall.hpp
<https://reviews.apache.org/r/33295/#comment137772>
Would be good to document that this is an exact match only, so it does not match substrings or wildcards. For example, if `/files` or `/files/*` is disabled, connections to `/files/browse.json` will still be allowed through.
3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137773>
s/will be test/will be tested/
3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137774>
s/the appear/they appear/
3rdparty/libprocess/include/process/process.hpp
<https://reviews.apache.org/r/33295/#comment137775>
"@param rules The list of firewall rules which will be applied to incoming connections."
3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/33295/#comment137776>
s/rule/rules/
3rdparty/libprocess/src/process.cpp
<https://reviews.apache.org/r/33295/#comment137779>
Looks like this code is duplicated a few times now. Any chance you can dedupe it?
3rdparty/libprocess/src/tests/process_tests.cpp
<https://reviews.apache.org/r/33295/#comment137780>
Why the default "id" value? All your callers already specify a processId.
3rdparty/libprocess/src/tests/process_tests.cpp
<https://reviews.apache.org/r/33295/#comment137781>
Would like to see a test for nested endpoints, and maybe even wildcards, so that it's clear whether or not those work.
- Adam B
On May 26, 2015, 1:22 a.m., Alexander Rojas wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33295/
> -----------------------------------------------------------
>
> (Updated May 26, 2015, 1:22 a.m.)
>
>
> Review request for mesos, Adam B, Benjamin Hindman, Bernd Mathiske, and Till Toenshoff.
>
>
> Bugs: MESOS-2620
> https://issues.apache.org/jira/browse/MESOS-2620
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Introduces the interface `FirewallRule` which will be matched against incoming connections in order to allow them to be served or being blocked. For details, check the [design doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/Makefile.am 8aab0593f296c7aae71289f9bd6cf3eb3578a721
> 3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION
> 3rdparty/libprocess/include/process/process.hpp 392c74df3e8a122aecd3633dffdeec4bcbd1f097
> 3rdparty/libprocess/src/process.cpp e3de3cd6b536aaaf59784360aed546512dd04dc9
> 3rdparty/libprocess/src/tests/process_tests.cpp 67e582cc250a9767a389e2bd0cc68985477f3ffb
>
> Diff: https://reviews.apache.org/r/33295/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Alexander Rojas
>
>
Re: Review Request 33295: Added firewall mechanism to control access
on libprocess http endpoints.
Posted by Adam B <ad...@mesosphere.io>.
> On June 1, 2015, 1:06 a.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/firewall.hpp, lines 54-55
> > <https://reviews.apache.org/r/33295/diff/6/?file=964946#file964946line54>
> >
> > Please capitalize "The" beginning of each @param description.
>
> Alexander Rojas wrote:
> I do completely agree with you, and actually it was like that in an earlier version of the [patch](https://reviews.apache.org/r/33295/diff/1/?file=933068#file933068line270) however a previous review requested to change it because lowercase is the way we do it in libprocess (run `grep --include="*.[ch]pp" --include="*.[ch]" --exclude="*_tests.cpp" --exclude-dir="build" -RFIn '@param' .`)
I don't think that 10 improperly capitalized/punctuated comments in process.hpp dating back to 2011-12 necessarily indicate the intended trend across all of libprocess. If that's the case, you should remove the ending punctuation too. ;)
Ask @benh (sole author of those comments) if we can set a new standard for doxygen comments in libprocess.
- Adam
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33295/#review85950
-----------------------------------------------------------
On June 1, 2015, 8:52 a.m., Alexander Rojas wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33295/
> -----------------------------------------------------------
>
> (Updated June 1, 2015, 8:52 a.m.)
>
>
> Review request for mesos, Adam B, Benjamin Hindman, Bernd Mathiske, and Till Toenshoff.
>
>
> Bugs: MESOS-2620
> https://issues.apache.org/jira/browse/MESOS-2620
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Introduces the interface `FirewallRule` which will be matched against incoming connections in order to allow them to be served or being blocked. For details, check the [design doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/Makefile.am 8aab0593f296c7aae71289f9bd6cf3eb3578a721
> 3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION
> 3rdparty/libprocess/include/process/process.hpp 79d1719932a3fdc90b6247d3a77adee123e72435
> 3rdparty/libprocess/src/process.cpp e3de3cd6b536aaaf59784360aed546512dd04dc9
> 3rdparty/libprocess/src/tests/process_tests.cpp 67e582cc250a9767a389e2bd0cc68985477f3ffb
>
> Diff: https://reviews.apache.org/r/33295/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Alexander Rojas
>
>
Re: Review Request 33295: Added firewall mechanism to control access
on libprocess http endpoints.
Posted by Alexander Rojas <al...@mesosphere.io>.
> On June 1, 2015, 10:06 a.m., Adam B wrote:
> > 3rdparty/libprocess/include/process/firewall.hpp, lines 54-55
> > <https://reviews.apache.org/r/33295/diff/6/?file=964946#file964946line54>
> >
> > Please capitalize "The" beginning of each @param description.
I do completely agree with you, and actually it was like that in an earlier version of the [patch](https://reviews.apache.org/r/33295/diff/1/?file=933068#file933068line270) however a previous review requested to change it because lowercase is the way we do it in libprocess (run `grep --include="*.[ch]pp" --include="*.[ch]" --exclude="*_tests.cpp" --exclude-dir="build" -RFIn '@param' .`)
> On June 1, 2015, 10:06 a.m., Adam B wrote:
> > 3rdparty/libprocess/src/process.cpp, lines 1980-1989
> > <https://reviews.apache.org/r/33295/diff/6/?file=964948#file964948line1980>
> >
> > Looks like this code is duplicated a few times now. Any chance you can dedupe it?
Will do in a follow up patch!
- Alexander
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/33295/#review85950
-----------------------------------------------------------
On June 1, 2015, 5:52 p.m., Alexander Rojas wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/33295/
> -----------------------------------------------------------
>
> (Updated June 1, 2015, 5:52 p.m.)
>
>
> Review request for mesos, Adam B, Benjamin Hindman, Bernd Mathiske, and Till Toenshoff.
>
>
> Bugs: MESOS-2620
> https://issues.apache.org/jira/browse/MESOS-2620
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Introduces the interface `FirewallRule` which will be matched against incoming connections in order to allow them to be served or being blocked. For details, check the [design doc](https://docs.google.com/document/d/1JSJTJMJ6ZXLkCSmvOIabTLrjtqqr0E-u99Rx2BHR1hs/edit).
>
>
> Diffs
> -----
>
> 3rdparty/libprocess/include/Makefile.am 8aab0593f296c7aae71289f9bd6cf3eb3578a721
> 3rdparty/libprocess/include/process/firewall.hpp PRE-CREATION
> 3rdparty/libprocess/include/process/process.hpp 79d1719932a3fdc90b6247d3a77adee123e72435
> 3rdparty/libprocess/src/process.cpp e3de3cd6b536aaaf59784360aed546512dd04dc9
> 3rdparty/libprocess/src/tests/process_tests.cpp 67e582cc250a9767a389e2bd0cc68985477f3ffb
>
> Diff: https://reviews.apache.org/r/33295/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Alexander Rojas
>
>