Minimise all root-owned files/directories in the running CKAN container #80
Conversation
|
@EricSoroos - your expertise would be very valuable here if you get a chance to look at this - thanks! |
| @@ -89,7 +89,7 @@ RUN addgroup -g 92 -S ckan && \ | |||
|
|
|||
| # Create local storage folder | |||
| RUN mkdir -p ${CKAN_STORAGE_PATH} && \ | |||
| chown -R ckan:ckan ${CKAN_STORAGE_PATH} | |||
| chown -R ckan:ckan-sys ${CKAN_STORAGE_PATH} | |||
There was a problem hiding this comment.
Is this to let both the ckan and ckan-sys users write to this directory? Good idea but it might not work because sub-directories will be owned by the user that created them.
There was a problem hiding this comment.
No not really, I think the ckan user needs to own the /var/lib/ckan/ directory as it needs to create/update files and directories here during runtime. There is no ckan group anymore. I'd rather avoid opening directory permissions so the ckan-sys user has write access as that can get a little messy/complicated, however it is an option further down the track
| useradd -rm -d /srv/app -s /bin/bash -g ckan-sys -u 502 ckan-sys && \ | ||
| useradd -rm -d /srv/app -s /bin/bash -g ckan-sys -u 503 ckan |
There was a problem hiding this comment.
having home directories owned by the user is nice for keeping track of things like .bash_history when logging in to the container
There was a problem hiding this comment.
if the ckan user has the same primary group as ckan-sys we'll need to make sure the group permissions on all the ckan source files prevent writing. I'm not used to setting things up this way but there may be other issues as well.
There was a problem hiding this comment.
Yes, it is set up this way by default. The ckan user has write permissions only on the files/directories it needs to write into. The ckan-sys user does not have write access. However I have made the ckan-sys group the primary group for both ckan and ckan-sys users in case further down the track we need group write access for more granularity
| @@ -1,7 +1,7 @@ | |||
| [unix_http_server] | |||
| file = /tmp/supervisor.sock | |||
| chmod = 0777 | |||
There was a problem hiding this comment.
If we're still using supervisor this doesn't look like a safe set of file permissions. If we aren't running supervisor we could delete this file.
There was a problem hiding this comment.
Yes the plan is still to remove Supervisor. I see the "remove supervisor PR": #77 has been approved but not merged...Were you waiting for me to merge? I can...however I'd better bring in the recent changes to master to make sure I don't mess things up
There was a problem hiding this comment.
Yes I approved but didn't merge in case you there was some reason to wait for any other updates. We don't have releases or a stable branch for this repo yet. Please go ahead and merge if it makes sense
| # Create ckan and ckan-sys users and the ckan-sys group plus set up the storage path | ||
| RUN groupadd -g 502 ckan-sys && \ | ||
| useradd -rm -d /srv/app -s /bin/bash -g ckan-sys -u 502 ckan-sys && \ | ||
| useradd -rm -d /srv/app -s /bin/bash -g ckan-sys -u 503 ckan |
There was a problem hiding this comment.
same comment about home directories above
|
@wardi - I have been experimenting with bind mounts in the ckan dev images/containers and I have struggled with getting the ownership of files in the directory ( |
|
docker bind mounts on Mac OS are certainly different than in Linux. IIRC there's a Linux VM in between that's used to run all the containers and I have no idea how permissions are mapped between the host directories and the VM. I do remember that Mac OS bind mounted directories were many many times slower to access than normal linux filesystems so there's probably some network filesystem and translation being used in between. |
|
The mac bind mounts for docker have changed dramatically over the last ~5 years or so -- originally they where super slow, at least for individual ops. (actual transfer wasn't that bad, but latency was roughly like spinning rust). They've gone through an intermediate, unstable alternative, and now they're using the built in virtfs/virtualization framework, which I haven't really noticed as being bad. What I typically do if I need to shell in and match ids is: (though that's a canned script in a makefile, so I don't have to remember how to type all that) There's really no way to do this for the volume mounts themselves. |
…figuration files - Until ckan#172 and ckan/ckan-docker-base#80 to ckan-docker
Fixes: #79
To enhance the security of CKAN images and containers, it is recommended that all files and directories associated with the application be owned by a dedicated non-root user. Additionally, running CKAN processes under a separate non-root user account further reinforces system security by limiting the privileges available to any running service.
For CKAN 2.10, 2.11 and master images (base and dev)
User: ckan-sys (id=502)- owns the files/directories that are part of the application and supporting libraries
User: ckan (id=503) - runs the application processes, owns files and directories it needs write access to
There is also a ckan-docker update to be merged alongside with this change