On Mon, Mar 21, 2016 at 12:30 PM, Sage Weil <sage@xxxxxxxxxxxx> wrote: > 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. Ah, that is tickling my memory a little more and sounds better. I thought this was describing extra caps in the cephx ticket. > >> 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'... Yeah. -- 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
