On Mon, Mar 21, 2016 at 8:55 AM, Noah Watkins <noahwatkins@xxxxxxxxx> wrote: > This is a follow-up e-mail from the CDS meeting at the beginning of > the month regarding merging cls-lua (http://pad.ceph.com/p/cls-lua). I > want to clarify the semantics of what was discussed. > > # Class Load List > > Purpose: option to specify the names of object classes that are > permitted to be loaded. > > Format: `osd class load list = * | [class[ class[ ...]]` > 1) * any class may be loaded > 2) list of class names allowed > > Default: list of classes shipping in tree? > > Classes loaded as a dependency of another class are not required to be > listed. The `osd_open_classes_on_start` option is affected by > filtering based on this list. > > # 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. 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 second change would be to enable the class capabilities that > explicitly name classes. I see two formats. The first format only > specifies a class name: > > allow [match] class <name> > 1) execute any method > 2) does not need to be in `osd class default list` > > The second format specifies a class name and class cap as a generic string: > > allow [match] class <name> <classcap> > 1) execute class methods subject to classcap > 2) does not need to be in `osd class default list` > > I didn't see anything on how `classscap` is interpreted, so I'm > guessing that this is intended to be used as a way for classes to > enforce their own cap policies? I think that's right. -Greg > > If so, we'd have a new class method: > > - bool ClassHandler::ClassData::is_capable(std::string) > - where is_capable is passed OSDCapSpec::class_allow > > Thanks, > Noah > -- > 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 -- 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
