[Lava-users] lavacli: adding remote worker requires superuser

Neil Williams neil.williams at linaro.org
Thu Aug 30 07:38:27 UTC 2018


On Wed, 29 Aug 2018 at 17:11, Kevin Hilman <khilman at baylibre.com> wrote:

> On Tue, Aug 28, 2018 at 11:46 PM Neil Williams <neil.williams at linaro.org>
> wrote:
> >
> > On Tue, 28 Aug 2018 at 19:49, Kevin Hilman <khilman at baylibre.com> wrote:
> >>
> >> On Tue, Aug 28, 2018 at 12:41 AM Neil Williams <
> neil.williams at linaro.org> wrote:
> >> >
> >> > On Tue, 21 Aug 2018 at 22:46, Kevin Hilman <khilman at 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.">
>


-- 

Neil Williams
=============
neil.williams at linaro.org
http://www.linux.codehelp.co.uk/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linaro.org/pipermail/lava-users/attachments/20180830/bdecfcd5/attachment.html>


More information about the Lava-users mailing list