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

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?

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.

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

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.

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