On Wed, 29 Aug 2018 at 17:11, Kevin Hilman khilman@baylibre.com wrote:
On Tue, Aug 28, 2018 at 11:46 PM Neil Williams neil.williams@linaro.org wrote:
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.
Thanks, that seems to work.
The next blocker to having a non-superuser remote worker is the adding the dispatcher_ip, which also requires superuser privileges[1], and doesn't appear to have an individual user permission ACL.
Assuming ZMQ encryption between master/slave, is it possible to have a remote worker without admin privileges? Is this something that has been validated?
No. Adding and managing workers is solely a superuser task because such operations can fundamentally change the topology of the lab and undermine ongoing CI.
Kevin
[1] lab-slave-0_1 | Add dispatcher_ip 192.168.66.1 to lab-slave-0 lab-slave-0_1 | Traceback (most recent call last): lab-slave-0_1 | File "/usr/local/bin/setdispatcherip.py", line 11, in <module> lab-slave-0_1 | server.scheduler.workers.set_config("%s" % sys.argv[2], "dispatcher_ip: %s" % sys.argv[3]) lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 1243, in _call_ lab-slave-0_1 | return self._send(self._name, args) lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 1602, in __request lab-slave-0_1 | verbose=self.__verbose lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 1283, in request lab-slave-0_1 | return self.single_request(host, handler, request_body, verbose) lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 1316, in single_request lab-slave-0_1 | return self.parse_response(response) lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 1493, in parse_response lab-slave-0_1 | return u.close() lab-slave-0_1 | File "/usr/lib/python2.7/xmlrpclib.py", line 800, in close lab-slave-0_1 | raise Fault(**self._stack[0]) lab-slave-0_1 | xmlrpclib.Fault: <Fault 403: "User 'nonadminuser' is not superuser.">