Flexible file permissions handling at DSI Core Terminal

[qwofford]

DSI Core Terminals read and write files through Drivers. Each file that is read or written has exactly one UID, GID, and permissions setting.

Each process is associated with a UID, an effective (default) GID, and a collection of other GIDs. The ability to read files by a GID other than the effective GID complicates the process required to write files.

Consider the following scenario:

1. Greg launches a process with UID 1 and effective GID 2. Greg's GID collection is [1,2,3]
2. The process instantiates a DSI Core terminal
3. A DSI Driver reads a file with 1:3 ownership and a file with 1:2 ownership.
4. The Core Terminal is transloaded, merging the data of both files, losing ownership. It's OK for Greg to see this.
5. Greg calls Terminal().artifact_handler(interaction_type='put') and writes a file with the process UID and effective GID.
6. The resulting file has 1:2 ownership, which allows someone with a 2 GID to see some metadata which should only be seen by someone with 3.

This is only one example of how this can fail. We need to treat the cases of this failure formally to ensure we create as many files as we need to to maintain POSIX file security when files are written.

One way to handle this is to remember the permissions of a file that is read, and associate those permissions in the Terminal().active_metadata buffer per every column of data, and when a Terminal().artifact_handler(interaction_type='put') occurs, write a new file with the same permissions.

This is an important security feature that should be present in every DSI Driver, so it may make sense to implement this at the most fundamental Driver class available so that any downstream implementations will have the same capability. This could be a "private" method that is called in Driver().put_artifacts(...). The driver should check for this metadata, write the file with the same permissions as from the metadata, xor warn if no permissions data exists, and write metadata with UID:UID permissions and no other read, write, or execute permissions.

[DanielRJohnson]

Quincy touched on this a bit in the issue description, but this is a visual on how I'm imagining this solution: