On Mon, 21 Mar 2016, Gregory Farnum wrote: > On Mon, Mar 21, 2016 at 8:55 AM, Noah Watkins <noahwatkins@xxxxxxxxx> wrote: > > # Class Execute Capabilities > > > > Purpose: wire up class capabilities and add an option to specify the > > names of object classes are allowed to be used without explicit > > capabilities. > > > > ## Default Object Class List > > > > Format: `osd class default list = * | [class[ class[ ...]]` > > 1) * any class may be loaded > > 2) list of class names allowed > > > > Interpretation of this option is described below. > > > > ## Enabling Class Capabilities > > > > It looks like currently in OSDCap::is_capable() that 'x' and class > > read/write capabilities are checked. The first change would be to > > cross reference these checks with the `osd class default list` to > > ensure that the class is on the allowed list. > > Woah, no way. These are capabilities, and are additive. We and our > users are going to be very unhappy if the security meaning of one cap > changes depending on others. I'm not following. The meaning changes based on the config, not another cap. > So I take it you mean for those execute and load capabilities to be > applied to clients, not the OSD or class methods or something? In that > case we can just stick them as additional clauses within the class > cap, and I guess take the missing clause to be "all" or the default > set or something. The problem is that 'x' means any class, but that was a bad idea on our part. Users should really specify which classes they mean going forward, but for existing clusters that isn't being done, and we can't break those, nor should we give them access to any random new class that shows up on the system. This changes it to mean 'any class in the configured list of default classes, as specified by ceph.conf'... sage -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
