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. 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? 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
