`/var/www/html` belongs to the admin user

[abrain]

Following the change to the specific UID (see #8), the USER instructions were removed alltogether. However, the /var/www/html directory still belongs to the admin user.

$ ls -l /var/www
total 4
drwxrwxrwt 1 admin admin 4096 Mar 23 01:48 html

It may make sense to remove the following lines, if the user is not used anymore:

civicrm-docker/build/common-base/Dockerfile

Lines 68 to 74 in 6268ba3

	# Add an admin user
	RUN useradd admin --home-dir /home/admin --create-home
	# Run apache as admin
	RUN chown admin:admin /var/www/html

[michaelmcandrew]

Thanks @abrain - that's a good catch.

The change to run apache as www-data was made in haste do to a funding requirement to get something up and running.

It may well have been the right decision but there were a few things that we didn't fully think through. This is one of them.

Here is a summary of the changes that we made: 7778304...64ee356.

One of the things that I wouldn't mind thinking about some more is the use of commands like cv. See this issue, for example: #18.

Here's a quick summary:

• cv (and other similar commands) often want to create files (config, cache, etc.) in a users home directory.
• www-data has it's home directory set as /var/www (in this instance) which seems like a weird place to create these files (though maybe not)

For now I agree it makes no sense to chown admin:admin /var/www/html and further to not create that user if they are no longer needed. I've done that here: a8a5964

FWIW, I think this will also fix #18.

If anyone has any thoughts on whether it is reasonable run cv as the www-data user and to write to /var/www, let me know.

@ufundo / @totten - do you have thoughts on this by any chance?

[michaelmcandrew]

fwiw for now I have done this here: 2e77fd2

[frlan]

I was still able to reproduce a similar issue with a fresh CiviCRM 6.1.1 container and still see admin vs. www-data on paths used by cv -- related to #18

www-data@2a2b14edb55b:~/html$ cv upgrade:db 
[PHP Warning] mkdir(): Permission denied at phar:///usr/local/bin/cv/src/Command/UpgradeDbCommand.php:87

In UpgradeDbCommand.php line 88:
                                                                  
  Failed to initialize upgrade data folder: /var/www/.cv/upgrade  
                                                                  

[totten]

Regarding these bits....

cv (and other similar commands) often want to create files (config, cache, etc.) in a users home directory.
www-data has it's home directory set as /var/www (in this instance) which seems like a weird place to create these files (though maybe not)

and

Failed to initialize upgrade data folder: /var/www/.cv/upgrade

I haven't looked at the specifics behind this issue and don't claim to be an expert in container "best practices", but a few thoughts (in no particular order):

• In cv 0.3.62+, you can change this folder using the XDG_STATE_HOME variable (PR 243).

• My personal experience is that single-user structure (one POSIX principal for both CLI-administration and HTTP-runtime) is easier than two-user structure (separate POSIX principals for CLI-administration and HTTP-runtime).

• In cases with two-user, you have to define the general goal and relationship between the two users. IMHO, this is the kind of policy that seems plausible/useful:

  POSIX Principal	Access Level: Code folders	Access level: Data folders
  HTTP Runtime User	Read-only	Read-write
  CLI Admin User	Read-write	Read-write

  (N.B. If the HTTP runtime user has read-write access to code, then I don't see any real point in splitting the users. And if the CLI user doesn't have read-write access to data, then you get blocked from basic administration.)

  Making these permissions sticky/consistent usually requires some orchestration of POSIX-group/permission.

  • I personally find setfacl to be easiest to understand, but it's not perfect, and it may not translate to a Docker context.
  • There are more old-school techniques with umasks and shared-GID -- but I've always avoided that because it feels precarious to enforce on a full-server (with multiple users+entry-points). Hypothetically, that might work better in a Docker environment (which has more controlled entry-points).