[BUG] PTS for the logged in shell are owned by the wrong user, which prevents /dev/stdout & /dev/stderr to work

[bmc-msft]

To Reproduce

echo hi > /dev/stderr
echo hi > /dev/stdout

Observed Behavior

$ echo hi > /dev/stdout
bash: /dev/stdout: Permission denied
$ 
$ echo hi > /dev/stderr
bash: /dev/stderr: Permission denied
$ 

Expected behavior

On standard linux OS distros, /dev/stdout points to /proc/self/fd/1, which points to /dev/pts/NUMBER.

Note, the same is

Example from ubuntu:

$ ls -al /dev/stdout
lrwxrwxrwx 1 root root 15 Feb  1 10:24 /dev/stderr -> /proc/self/fd/1
$ ls -al /proc/self/fd/1
lrwx------ 1 user1 user1 64 Feb 11 14:06 /proc/self/fd/2 -> /dev/pts/14
$ ls -al /dev/pts/14
crw--w---- 1 user1 tty 136, 14 Feb 11 14:06 /dev/pts/14

Example on cloudshell:

$ ls -al /dev/stdout
lrwxrwxrwx 1 root root 15 Feb 11 19:01 /dev/stdout -> /proc/self/fd/1
$ ls -al /proc/self/fd/1
lrwx------ 1 user1 user1  64 Feb 11 19:08 /proc/self/fd/1 -> /dev/pts/0
$ ls -al /dev/pts/0
crw--w---- 1 root tty 136, 0 Feb 11 19:08 /dev/pts/0

Is this specific to Cloud Shell?

Yes.

Interface information

Using portal.azure.com, with Edge as my browser.

Additional context

Add any other context about the problem here.

[edyoung]

This is interesting. In Cloud Shell the shell process is spawned as a child by a process which connects to the websocket from the browser.

Does this pose an actual problem for your use of Cloud Shell?

[bmc-msft]

Yes.

[edyoung]

Since this behavior has been consistent since Cloud Shell first started, and this is the first time it has come up as an issue, I'm afraid it is not a very high priority at this time. If others have this problem, please +1.