better uid permissions example

Author: bparees

creating_images/guidelines.adoc

@@ -267,21 +267,29 @@ xref:s2i.adoc#creating-images-s2i[S2I Requirements] topic.
 [[use-uid]]
 *Support Arbitrary User IDs*
 
-In order to support running containers with volumes mounted in a secure fashion,
-images should be capable of being run as any arbitrary user ID. When
-{product-title} mounts volumes for a container, it configures the volume so it
-can only be written to be a particular user ID, and then runs the image using
-that same user ID. This ensures the volume is only accessible to the appropriate
-container, but requires the image be able to run as an arbitrary user ID.
-
-Running a container with an arbitrary user ID also has the benefit of ensuring
-that a process which is able to escape the container due to a vulnerability in
-the container framework will not have specific user permissions on the host
-system.
-
-To accomplish this, directories that must be written to by processes in the
-image should be world-writable. In addition, the processes running in the
-container must not listen on privileged ports (ports below 1024).
+To provide additional security against processes escaping the container due
+to a container engine vulnerability and thereby achieving escalated permissions 
+on the host node, {product-title} runs containers using an arbitrarily assigned uid by default.
+
+For an image to support running as an arbitray user, directories and files that may be 
+written to by processes in the image should be owned by the root group and read/writable 
+by that group.  Files to be executed should also have group execute permissions.  The following
+Dockerfile fragment sets root group ownership and permissions for *_/some/directory_* and all child 
+directories:
+
+----
+RUN chgrp -R 0 /some/directory
+RUN chmod -R g+rw /some/directory
+RUN find /some/directory -type d -exec chmod g+x {} +
+----
+
+Adding these commands to your Dockerfile sets the directory and file permissions to allow users
+in the root group to access them in the built image.  Because the container user is always a member 
+of the root group, the container user can read and write these files.  The root group does not have 
+any special permissions (unlike the root user) so there are no security concerns with this arrangement.
+
+In addition, the processes running in the container must not listen on privileged ports (ports below 
+1024), since they are not running as a privileged user.
 
 Because the user ID of the container is generated dynamically, it will not have
 an associated entry in *_/etc/passwd_*. This can cause problems for applications

install_config/persistent_storage/pod_security_context.adoc

@@ -127,7 +127,7 @@ It may not be immediately obvious which SCC was matched by a pod, so the command
 above can be very useful in understanding the UID, supplemental groups, and
 SELinux relabeling in a live container.
 
-Any SCC with a strategy set to *RunAsAny* allows arbitrary values for that
+Any SCC with a strategy set to *RunAsAny* allows specific values for that
 strategy to be defined in the pod definition (and/or image). When this applies
 to the user ID (`*runAsUser*`) it is prudent to restrict access to the SCC to
 prevent a container from being able to run as root.
@@ -305,7 +305,7 @@ general, containers should not run as root, so in this NFS example, containers
 which are not run as UID *65534* or are not members the group *5555* will not be
 able to access the NFS export.
 
-Often, the SCC matching the pod does not allow an arbitrary user ID to be
+Often, the SCC matching the pod does not allow a specific user ID to be
 specified, thus using supplemental groups is a more flexible way to grant
 storage access to a pod. For example, to grant NFS access to the export above,
 the group *5555* can be defined in the pod definition: