On Tue, 28 Aug 2018 at 19:49, Kevin Hilman <khilman@baylibre.com> wrote:
On Tue, Aug 28, 2018 at 12:41 AM Neil Williams <neil.williams@linaro.org> wrote:
>
> On Tue, 21 Aug 2018 at 22:46, Kevin Hilman <khilman@baylibre.com> wrote:
>>
>> Hello,
>>
>> When trying to use lavacli to add a remote worker, it works fine if
>> the user is a superuser.
>
>
> Adding remote workers to an instance would be an easy way to DDOS an instance by swamping the ZMQ ports with fake attempts - the process needs to be under the control of the admins of the instance.
>
> If the remote worker is properly configured, it will register itself automatically - this is why encryption of the master:slave communication is so important. A LAVA master which is visible to the internet should always use encryption.

All masters and slaves are in control of the admins and encryption is
enabled.  The per-user permissions still do not work.

However, all of this still begs the question: why do those per-user
permissions even exist if they don't do anything because superuser
privileges are required?  If that's a hard requirement, shouldn't
those permissions just be removed so it's not confusing for admins?

> In most cases, the lavacli workers add command isn't required.

Ahh... so, IIUC, when a new worker connects, it automatically adds
itself. so a "workers add" command isn't needed?

Yes - with an up to date lava-master, (2018.5 and later IIRC, possibly a release or two earlier, I'd have to check) , the process is automatic.
 

What are the cases where a "workers add" is actually needed then?

lavacli needs to cope with older versions of lava-master. 

We can update the manpage and --help output of lavacli - will also check to see if the XMLRPC call itself should become a no-op in the next release.


--

Neil Williams
=============
neil.williams@linaro.org
http://www.linux.codehelp.co.uk/