A possible alternative abstraction for permissions

[andytson-inviqa]

Assumes for setfacl/stickybit that all users are umask 0002

It doesn't have the performance improvements of #332 yet, though I'm unsure if that's possible with setfacl

[kierenevans]

I've given this a bit of a test in https://github.com/continuouspipe/dockerfiles/tree/feature/use-abstracted-permissions with a few fixes for syntax but composer wasn't able to install.
I should get time to look at this again in the next couple of weeks, as it will be a great speed boost :)

[kierenevans]

Results from an experiment in a magento2 image, where we have RUN container build && getfacl . RUN getfacl /app.
It doesn't seem like the ACLs get persisted between image layers:

+ setfacl -R -m user:build:rwX -m default:user:build:rwX -m user:www-data:rwX -m default:user:www-data:rwX pub/media pub/static var/log var/report var/generation generated
+ chmod -R ug+rw,o-rwx pub/media pub/static var/log var/report var/generation generated
getfacl: Removing leading '/' from absolute path names
# file: app
# owner: root
# group: root
user::rwx
user:www-data:r-x
user:build:rwx
group::r-x
mask::rwx
other::---
default:user::rwx
default:user:www-data:r-x
default:user:build:rwx
default:group::r-x
default:mask::rwx
default:other::r-x

Removing intermediate container 7619c21002bd
 ---> 8ae9f8901b39
Step 5/5 : RUN getfacl /app
 ---> Running in 9952fee6d01a
getfacl: Removing leading '/' from absolute path names
# file: app
# owner: root
# group: root
user::rwx
group::rwx
other::---

Then inside the container built from the image:

root@4d75a905a639:/app# getfacl .
# file: .
# owner: root
# group: root
user::rwx
group::rwx
other::---

We could run another pass at setfacl upon container startup perhaps?

[kierenevans]

Stickybit fares a lot better and is persisted between image layers, though we'd need to be even more careful who we create directories and files as.

The umask for root/build/www-data is 0022, which means that any files created by root/www-data will not let the group we've declared (buildwww-data) write to it.

This is probably okay as the existing mkdir/file creation will be explicitly chmod/chowing after creation.
EDIT: I made a mistake below - umask when doing su - build is set to 0002 instead of 0022. A better test is sudo -u build -E HOME=/home/build bash

root@5739d5e084a9:/app# touch pub/static/frontend/foo
root@5739d5e084a9:/app# ls -la !$
-rw-r--r-- 1 root buildwww-data 0 Mar 18 09:32 pub/static/frontend/foo
root@5739d5e084a9:/app# su - build
build@5739d5e084a9:~$ touch /app/pub/static/frontend/foo2
build@5739d5e084a9:~$ ls -la !$
-rw-rw-r-- 1 build buildwww-data 0 Mar 18 09:33 /app/pub/static/frontend/foo2
build@5739d5e084a9:~$ logout
root@5739d5e084a9:/app# umask
0022
root@5739d5e084a9:/app# su - build
build@5739d5e084a9:~$ umask
0002

For some reason magento is creating directories as 0777 which didn't happen in the master branch's version of the magento2 image, but that might be due to the lack of an explicit chmod+chown at the end of image build:

EDIT: This is also happening on the master branch, it's just the chmod+chown at the end of do_magento2_build hides this issue.

root@2880a463a608:/# ls -la app/var/cache/
total 72
drwxrwsr-x 18 build buildwww-data 4096 Mar 18 09:59 .
drwxrwsr-x  9 build buildwww-data 4096 Mar 18 09:58 ..
drwxrwsrwx  2 build buildwww-data 4096 Mar 18 09:58 mage--0