> On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.hpp, lines 179-180 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448443#file1448443line179> > > > > Do we still need this given that we only accept > > `_LINUX_CAPABILITY_VERSION_3`?
Good point. We only support `_LINUX_CAPABILITY_VERSION_3` so there is no need to store it. > On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.hpp, lines 124-134 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448443#file1448443line124> > > > > I'd suggest that we don't create a class `Capabilities`. Instead, let's > > put all methods under namesapce `capabilities`. Looks like we just need to > > cache `lastCapability` (`/proc/sys/kernel/cap_last_cap`), which should not > > change. There's no reason to keep a class for that. > > > > ``` > > namespace capabilities { > > Try<Nothing> initialize(); > > Try<ProcessCapabilities> get(); > > Try<Nothing> set(const ProcessCapabilities& set); > > ... > > } > > ``` Are you suggesting we create a global variable to hold `lastCapability`? It looks that one could only be set in `capabilities::initialize`, so we'd require a way to denote unset/invalid state, so we'd either need something like e.g., an `Option` which opens the door the nasty destruction order bugs, or semantically worse, use e.g., a signed type to store an unsigned value and use values < 0 to denote invalid values. As much as I would like to get rid of an extra class here, using a class to control that state appears simpler to me. > On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.hpp, line 196 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448443#file1448443line196> > > > > I'd prefer this method returns `Set<Capability>`. > > > > We should have a general way to convert `CapabilityInfo` to > > `Set<Capability>`, and vise versa, instead of having different return type > > (or parameter type) mixed in this file. If we'd just return a `Set` we'd need to use an empty set for both the case of no supported capabilities, and the error case. What about using a `Try<Set<Capability>>` instead? - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50266/#review143038 ----------------------------------------------------------- On Aug. 10, 2016, 7:03 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/50266/ > ----------------------------------------------------------- > > (Updated Aug. 10, 2016, 7:03 p.m.) > > > Review request for mesos and Jie Yu. > > > Bugs: MESOS-5051 > https://issues.apache.org/jira/browse/MESOS-5051 > > > Repository: mesos > > > Description > ------- > > This change introduces basic API for linux capabilities. This is not a > comprehensive API but is strictly limited to the need for securing Mesos > containers using linux capabilities. > > This patch is based on the work in https://reviews.apache.org/r/46370/. > > > Diffs > ----- > > src/CMakeLists.txt 1286ee08fe2d60867326a1f2585f054c20b52208 > src/Makefile.am 1a9b083493612cf610b80ac5a1c11c29d6302933 > src/linux/capabilities.hpp PRE-CREATION > src/linux/capabilities.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/50266/diff/ > > > Testing > ------- > > `make check` and `sudo make check` (Debian jessie, gcc-4.9.2, w/o > optimizations) > > > Thanks, > > Benjamin Bannier > >
