Re: [libvirt-jenkins-ci PATCH 2/5] guests: templates: Introduce a gitlab-runner RC init service template
On Tue, Mar 31, 2020 at 04:42:10PM +0200, Andrea Bolognani wrote:
On Thu, 2020-03-26 at 14:33 +0100, Erik Skultety wrote:
> guests: templates: Introduce a gitlab-runner RC init service template
"RC init" is sort of a loaded term, I'd just call out FreeBSD
directly.
> +++ b/guests/playbooks/update/templates/gitlab-runner.j2
> @@ -0,0 +1,32 @@
> +#!/bin/sh
> +# PROVIDE: gitlab_runner
> +# REQUIRE: DAEMON NETWORKING
> +# BEFORE:
> +# KEYWORD:
This seems to be heavily based on [1], so maybe include a reference
to that URL somewhere.
Since it's not 1:1, I'll put it into the commit message.
> +user="{{ flavor }}"
> +user_home="/home/{{ flavor }}"
Either use substitution for {{ flavor }} both here and in the systemd
service, or in neither. Personally I'd go for the latter, since it's
not really buying us much.
True, it can be hardcoded.
> +gitlab_runner_start()
> +{
> + export USER=${user}
> + export HOME=${user_home}
> + export PATH=${PATH}:/usr/local/bin/:/usr/local/sbin/
> + if checkyesno ${rcvar}; then
> + cd ${user_home}
> + /usr/sbin/daemon -p ${pidfile} ${command} ${command_args} >
/var/log/gitlab-runner.log 2>&1
The version in the official documentation does this a little
differently... I guess the difference is that in their case the
gitlab-runner application is running as the gitlab user, wereas in
ours the daemon is running as root but is instructed to execute
workloads as the gitlab user. The latter seems fine, as that's what
happens on Linux as well, but have you fully considered the security
implications?
It is different because I wanted a unified behaviour on Linux and FreeBSD.
What security implications are you talking about, can you be more specific? The
machines are going to run behind a NAT, the daemon executing the service should
be trusted by default (otherwise, engage the tin foil hat mode), the gitlab
user doesn't have sudo permissions (and we should not trust this user), and in
later patches I setup a random root password, so that only access via an SSH
pub key to the root account is allowed. Alternatively, we could set up another
service user which will have sudo (not passwordless) access and will not run
any services, so that root isn't accessible over the network, would consider
that as suitable precaution measures?
--
Erik Skultety