Some jobs cannot run as root

[Colin Watson]

lpcraft runs jobs as root inside the container. However, there are some reasonable jobs that call code that refuses to run as root. For example, test suites that use a local PostgreSQL instance (e.g. lp-signing) call `initdb`, which fails with an error if run as root. This requires fairly horrible workarounds like this:

        run: |
            # PostgreSQL's initdb refuses to run as root, so drop privileges
            # for the test.
            getent passwd lp-signing-test >/dev/null || useradd -m -U lp-signing-test
            tmpdir="$(mktemp -d)"
            cleanup () { rm -rf "$tmpdir"; }
            trap cleanup EXIT
            cp -a . "$tmpdir/lp-signing"
            chown -R lp-signing-test:lp-signing-test "$tmpdir"
            runuser -u lp-signing-test -- ...

I'm not entirely sure what the best solution is; we may need to try out a few alternatives. One reasonable approach might be something like a `user` key which would ensure that that user exists, arrange for the project tree to be owned by that user (note that it's currently under `/root`, and other users can't see subdirectories of that ...), and drop privileges to that user. There may be other approaches. Note that the username can matter; for example, when testing this, I found that lp-signing's test suite specifically fails if run as an "lp-signing" user, because it wants to create a PostgreSQL role by that name which then conflicts with an automatically-created one.

We could also consider not running as root by default, though perhaps that's more trouble than it's worth since there may already be some jobs that rely on being able to programmatically fiddle with their environment as root in `run` - I don't know.

[Colin Watson (cjwatson)]

https://code.launchpad.net/~cjwatson/lpci/+git/lpci/+merge/429388 makes a small start at this, by at least making the project tree be in a place where non-root users can see it.