fails to start when confined in a snap

[Paul Collins]

I attempted to package a simple WSGI app in an Ubuntu snap with gunicorn, and ran into a problem with gunicorn vs. the Snap security policy.

The policy forbids calling chown at all, whereas the workers.workertmp.WorkerTmp class relies on the default and historically unproblematic behaviour of silently succeeding when the UID/GID are the same as the calling process's.

I've attached a patch that attempts to short-circuit chown when it would be a no-op, which is the case when gunicorn is run as root in a snap, and this patch lets my app work when confined.

snaps also do not currently allow setuid, etc., and so there's no sense in trying to create a gunicorn-using snap that starts as root and then drops privileges. For more information on the snap security policy, please visit: https://developer.ubuntu.com/en/snappy/guides/security/
and https://developer.ubuntu.com/en/snappy/build-apps/debug/

[Ubuntu Foundations Team Bug Bot (crichton)]

The attachment "skip chown when it would be a no-op" seems to be a patch. If it isn't, please remove the "patch" flag from the attachment, remove the "patch" tag, and if you are a member of the ~ubuntu-reviewers, unsubscribe the team.

[This is an automated message performed by a Launchpad user owned by ~brian-murray, for any issues please contact him.]

[Paul Collins (pjdc)]

I managed to completely forget what a hack the previous patch was between writing it and posting it. So please definitely ignore that one.

Here's a more sensible patch that that will skip chowning the worker temporary file if we're running as root and we know we're not going to try to drop privileges.

If Ubuntu snaps gain support for assigning non-root UIDs and GIDs to confined apps, gunicorn will probably need more work, even with this patch applied, because utils.set_owner_process() assumes that setuid(getuid()) will successfully no-op, whereas the Ubuntu snap security policy would probably still block setuid() entirely.

But this seems to be enough for now, and my snapped Web app still works with this patch applied in place of the previous one.

[Jamie Strandboge (jdstrand)]

Note that snapd 2.22 allows snaps to chown to root:root. You might be interested in https://bugs.launchpad.net/snappy/+bug/1606510/comments/14

[Celso Providelo (cprov)]

Using snap 2.22.5 and still getting:

{{{
Time: Feb 22 23:45:01
Log: auid=4294967295 uid=1000 gid=1000 ses=4294967295 pid=6630 comm="python3" exe="/usr/bin/python3.5" sig=31 arch=c000003e 92(chown) compat=0 ip=0x7f2e7d6d6717 code=0x0
Syscall: chown
Suggestions:
* don't copy ownership of files (eg, use 'cp -r --preserve=mode' instead of 'cp -a')
* adjust program to not use 'chown'
}}}

running `gunicorn ... -u 1000 -g 1000 --worker-tmp-dir $SNAP_USER_DATA` (-u & -g doesn't make any difference)