Support controlling the user, group, and permissions of the application files

[tmds]

The current implementation unconditionally uses -rwxr-xr-x. and root:root for the application files.

It would be nice to be able to:

• control the umask (permission filter)
• control the user/group of these files (and their containing directory).

The umask could be made settable through a property, like ContainerAppUMask. When set, the effective permissions of a file/directory are the result of using the file's owner permission for owner, group and other, and applying ContainerAppUMask to it. That means, the effective permissions are as if the application was published under umask $(ContainerAppUMask).

Controlling the user/group of these files would allow to match their ownership with the app user, and thus allowing that user to change the files on a running container. It could be done through properties like: ContainerAppOwner, ContainerGroup which are set to a uid/gid. Or some property like: ContainerAppOwnedByUser=true which makes the ownership match with the app user and group.

cc @baronfel @richlander @omajid @aslicerh

[baronfel]

We do need to do this, but I think it'll require a bit of a rework of the current model.

Images are made of many Layers, and right now the tooling creates a single Layer with all app dependencies and the same permissions (root) inside the CreateNewImage Task. These knobs should be settable in MSBuild, I agree. Other tooling (like Jib) allows for defining the Layers as data structures (including user/group and permissions) and that's the model I think we should follow here. We should be able to do something like:

<ContainerLayer Include="$(PublishDir)/**/*" 
				Destination="/app" 
				User="$(ContainerAppUserId)" 
				Group="$(ContainerAppGroupId)" 
				Permissions="644" />

and have the tooling generate those tarballs with the correct permissions in-order.

[tmds]

<ContainerLayer...

That is very flexible, it allows including different files with different permissions in the layer.

I'm looking to control the 'default values' for User, Group, and Permissions.

We should be able to implement those separate from introducing ContainerLayer (which requires a more complex implementation).

Permissions="644"

note: Unix permissions for directories require the 'x' bit. If you want to avoid a separate permission parameter for directories, we can take this value and use it for files. For directories, we can add an 'x' for each 'r' permission. So 644 for files (rw-r--r--), implies 755 for directories (rwxr-xr-x).

[richlander]

Is this the same as:

https://docs.docker.com/engine/reference/builder/#copy

[baronfel]

Yes, exactly - it allows fine grained control of the permissions of copied files.

[tmds]

My request is less fine-grained than the suggested ContainerLayer which enables using different permissions for different files.

I'm looking to control the values which are currently fixed to Gid = Uid = 0 and Mode = -rwxr-xr-x. on construction here:

https://github.com/dotnet/sdk-container-builds/blob/6da3967241627967be7dc025382f7dc343a8a6a9/Microsoft.NET.Build.Containers/Layer.cs#L77-L82

Can we add parameters to control these?

[tmds]

When the tooling is used with Microsoft images, the non-root user does not have write-access to the application folder since that application folder is owned by root and only writable by the owner.

That means it's OK for the non-root user of the Red Hat images to also to not have write access to the application folder.

I no longer consider this a must-have to support the Red Hat images.

I'm fine if the issue gets closed, or stays open for others to declare an interest in controlling the application folder permissions.

[Devqon]

We also need some fine-grained control over directory permissions from the app user. Our use-case is that the application unpacks a file in the app's root directory at runtime, which is done inside a library (no control over the unpacking and its destination).

Of course you might consider that this should not be the way to do so, but the point is that we have no control over it. The current workaround is to manually attach to the container after redeploy and reconfigure the app directory ownership with chown