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?
>
>
> [1] https://docs.gitlab.com/runner/install/freebsd.html
--
Erik Skultety
