Functionality for pseudoterminals in linux sandbox

[crydell-ericsson]

As brought up in issue #5373 , the Linux sandbox does not allow processes that run inside it to open pseudoterminals. These changes enable this by addressing the two main underlying issues:

• /dev/pts can not be read-only if a new pseudoterminal is to be created. These changes make dev/pts writable when remounting file systems during sandbox initialization.
• The group associated with pseudoterminals is "tty". After creating a new pseudoterminal, its gid has to be changed. If there is no gid mapping in the user namespace that corresponds to "tty", this group will not be known inside the sandbox. This causes issues in some Linux distributions, since they do not allow changing the group of a file to one that is not known inside the current user namespace. These changes map the gid of the user to the one corresponding to "tty" inside the sandbox in order to avoid this issue.

These changes introduce the -P flag to linux-sandbox in order to control whether or not the changes are applied, and the --sandbox-explicit-pseudoterminal to bazel in order to set this when calling bazel.

[aiuto]

This review is just general comments. I don't know enough about the sandbox to determine if this is a general purpose patch, or if we'll be back for a new design the second someone wants it for BSD or NIX. Also, it is not clear to me from the comments in #5373 that we should even do this.

[aiuto]

It does not look like there is any option to use other gid values.

[crydell-ericsson]

The intended meaning is that setting the flag would override anything that would otherwise alter the gid within the user namespace, e.g. if --sandbox_fake_username is set or if REQUIRES_FAKEROOT evaluates to true. I could rephrase this if it's unclear.

[aiuto]

We'll need to have someone who owns sandboxing review this. I added @philwo because of comments in the original bug.

[philwo]

Thank you @crydell-ericsson! Ideally I'd like to avoid adding yet another flag... is there a way to automatically detect what the right thing to do is?

Could we just always mount /dev/pts and somehow map or make the tty group usable inside the sandbox without explicitly changing to it?

[crydell-ericsson]

Could we just always mount /dev/pts

I think we should be able to always have /dev/pts mounted as writable, yes. I don't know of any situations where this would reasonably cause issues, it was mostly included with the flag as a precaution.

and somehow map or make the tty group usable inside the sandbox without explicitly changing to it?

I'm not sure how this could be done in a way that would still let this functionality be used by an unprivileged user. From the man page of user_namespaces(7):

   In order for a process to write to the /proc/[pid]/uid_map
   (/proc/[pid]/gid_map) file, all of the following permission
   requirements must be met:
   
   [...]

   5. One of the following two cases applies:

      *  Either the writing process has the CAP_SETUID (CAP_SETGID)
         capability in the parent user namespace.

         +  No further restrictions apply: the process can make
            mappings to arbitrary user IDs (group IDs) in the parent
            user namespace.

      *  Or otherwise all of the following restrictions apply:

         +  The data written to uid_map (gid_map) must consist of a
            single line that maps the writing process's effective
            user ID (group ID) in the parent user namespace to a
            user ID (group ID) in the user namespace.

         +  The writing process must have the same effective user ID
            as the process that created the user namespace.

         +  In the case of gid_map, use of the setgroups(2) system
            call must first be denied by writing "deny" to the
            /proc/[pid]/setgroups file (see below) before writing to
            gid_map.

Ideally you would be able to make two gid mappings, one tty->tty mapping and one arbitrary mapping for the gid in the parent namespace. This would not be possible if we want to run bazel as an unprivileged user, since only a single mapping can be done without granting the CAP_SETGID capability to the process in the parent namespace.

[crydell-ericsson]

Just thought I'd check in on the progress of this pull request; is there any additional information needed for this?

[philwo]

Thank you for the information, @crydell-ericsson. It's too bad that the best solution requires CAP_SETGID. 😞 I agree with your thoughts.

@larsrc-google Shall we merge this as is? Looks clean to me and all changed behavior is behind a flag.

[larsrc-google]

@crydell-ericsson This PR is out of date, could you update it?