[Bug 1611603] Re: fails to start when confined in a snap

[Paul Collins]

** Description changed:

  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
  gunicorn.worker.WorkerTemp 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/
+ 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/

** Description changed:

  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
- gunicorn.worker.WorkerTemp class relies on the default and historically
+ 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/

-- 
You received this bug notification because you are a member of Ubuntu
OpenStack, which is subscribed to gunicorn in Ubuntu.
https://bugs.launchpad.net/bugs/1611603

Title:
  fails to start when confined in a snap

Status in gunicorn package in Ubuntu:
  New

Bug description:
  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/

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/gunicorn/+bug/1611603/+subscriptions