Plugin access control

Stefan_Cohen · June 4, 2020, 6:57pm

Hi. I have implemented a somewhat dangerous feature for the next release of dashboard. The feature is called "Command Sensors" and will display the stdout/stderr output of configured shell commands in dashboard widgets. The purpose of this feature is to allow creative users to access and display pretty much any info available thru the platform where OctoPrint runs (shell commands, scripts, etc...). Each command is executed by the plugin backend and will run in a shell with the privileges of the octoprint service via a python subprocess.Popen. This flexibility comes with the downside that given access to the plugin configuration, any shell command can be executed...

Here is what it currently looks like:

I'm not up to speed with the Access Control improvements in 1.4 so my question is what you think would be the proper way to secure this feature while maintaining most of the flexibility it provides. Any ideas?

jneilliii · June 5, 2020, 3:24pm

Because of the danger with this I would think you would want to implement a custom access permission and then the user has the ability to enable that permission within the user configuration. By making that a manual process you are basically telling them, this is dangerous and is a kind of opt-in scenario.It even has a dangerous flag that allows you to state it as such.

https://docs.octoprint.org/en/master/plugins/hooks.html#octoprint-access-permissions

I haven't worked with it personally, but I assume you can then do a knockout binding on the custom permission, similar to this...

github.com

OctoPrint/OctoPrint/blob/6232a04e52fbf09a8b912590718764fccc3598ba/src/octoprint/templates/tabs/temperature.jinja2#L8


{% if enableTemperatureGraph %}
    <div class="row-fluid">
        <div id="temperature-graph" style="width: 100%"></div>
    </div>
{% endif %}
<div class="row-fluid">

    <table id="temperature-table" class="table table-bordered table-hover" data-bind="visible: loginState.hasPermissionKo(access.permissions.CONTROL)">
        <tr>
            <th class="temperature_tool"></th>
            <th class="temperature_actual" title="{{ _('Current actual temperature as reported by your printer')|edq }}">{{ _('Actual') }}</th>
            <th class="temperature_target" title="{{ _('Current target temperature as reported by your printer')|edq }}">{{ _('Target') }}</th>
            <th class="temperature_offset" title="{{ _('Offset to apply to temperature commands sent from files')|edq }}">{{ _('Offset') }}</th>
        </tr>
        <!-- ko foreach: tools -->
        <tr data-bind="template: { name: 'temprow-template' }"></tr>
        <!-- /ko -->
        <tr data-bind="template: { name: 'temprow-template', data: bedTemp }, visible: hasBed"></tr>

Stefan_Cohen · June 5, 2020, 9:17pm

Perfect. Thanks!

OllisGit · June 6, 2020, 8:16pm

I also need custom permissions for my PrintJobHistory (readonly/edit a job) and found the above link,
BUT you keep in mind that this is not available at OP 1.3.x. It only works with 1.4.x

Maybe a good approach to "push" the users to upgrade -> less testing effort for plugin-develeopers.

Or @jneilliii, @Stefan_Cohen do you test your plugins with all combinations of OP1.3/1.4 Py2/3 ???

jneilliii · June 6, 2020, 8:23pm

I don't, I always test in latest OctoPrint personally. I don't think any of my plugins as of yet have those in them, so hasn't been a problem for me yet.

Stefan_Cohen · June 6, 2020, 9:08pm

Same here. Only latest.