> 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. > > Benjamin Bannier wrote: > 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?
I made this a member function, as we discussed OTR. This allows us to return a `Set<Capability>` since this approach requires a vaild `Capabilities`. > 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); > > ... > > } > > ``` > > Benjamin Bannier wrote: > 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. Dropping this as discussed offline. > On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.hpp, lines 136-137 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448443#file1448443line136> > > > > I don't think this is needed. `getAllSupportedCapabilities` is > > sufficient. This can indeed be removed now that `getAllSupportedCapabilities` is a member function. > On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.cpp, line 191 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448444#file1448444line191> > > > > As I mentioned above, this should be the `initialize` function. Dropping this as we keep on using a `Capabilities` class instead of free function.s > On July 22, 2016, 2:32 a.m., Jie Yu wrote: > > src/linux/capabilities.hpp, line 171 > > <https://reviews.apache.org/r/50266/diff/1/?file=1448443#file1448443line171> > > > > This function is pretty high level. I don't think it belongs here. > > Looking at other capability libraries like > > https://github.com/syndtr/gocapability/tree/master/capability, it's not > > there. Let's move this out of this patch first. We discussed pulling this function out of this patch (I guess a similar argument could be made for `Capabilities::keepCapabilitiesOnSetUid`), and literally inlining them at the call sites. While the latter could be implemented as a free function, the former requires `Capabilities` state, so one would either need to pass such state in, or keep it a member. Regard inlining, it strongly looks to me as if that way we would impose dealing with very low-level code on users (e.g., preparing arguments for `capset`). It appears as if `capabilities` or `Capabilities` might just be the right spot for this code; otherwise it seems to me we wouldn't provide a complete toolbox. Of course it is possible to simply rip this code out for the moment, and potentially add it later. What do you think? - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/50266/#review143038 ----------------------------------------------------------- On Aug. 10, 2016, 9:14 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, 9:14 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 > >
