tty device used inside toolbox gets odd permissions on host causing pinentry/gpg-agent to not work

**Describe the bug**

My setup includes running gpg-agent on my host and doing development (git commit, etc) inside my toolbox container. When I git-commit I sign the commits, which means the process talks to the agent that then runs a pinentry program to ask the user for the passphrase.

When running in the terminal I prefer for the passphrase to be asked to me in the terminal window and not in a popup. So I'll `unset DISPLAY` to force it to use the terminal window. This stopped working sometime in the past few months. I finally tracked down some more information on why.

When running inside toolbox the permissions on my tty device are as expected:

```
$ ls -l $(tty)
crw--w----. 1 root nobody 136, 14 Sep 27 13:37 /dev/pts/14
```

However outside of toolbox (from the perspective of the host) the
permissions look odd:

```
[dustymabe@media ~]$ id
uid=1001(dustymabe) gid=1001(dustymabe) groups=1001(dustymabe) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[dustymabe@media ~]$ ls -l /dev/pts/14
crw--w----. 1 100000 tty 136, 14 Sep 27 14:39 /dev/pts/14
```

I would expect the owner of the tty to be the user who launched the toolbox container (`1001`). If I change the ownership to the expected UID then my pinentry program appropriately asks for the passphrase on the same terminal window (inside toolbox) where I am running `git commit`.

I'm running Fedora 33 with:

```
$ rpm -q toolbox podman
toolbox-0.0.95-1.fc33.x86_64
podman-2.1.0-0.187.rc2.fc33.x86_64
```

Indeed if I go back to an old machine I haven't updated in a while I can see that the permissions are what I would expect them to be. This out of date machine has:

```
[dustymabe@hattop ~]$ rpm -q toolbox podman
toolbox-0.0.18-1.fc31.noarch
podman-1.8.0-2.fc31.x86_64
```

**Steps how to reproduce the behaviour**

1. Launch toolbox container
2. Inspect owner inside the container: `ls -l $(tty)`. Should show up as `root` since you are inside a user namespace.
3. Inspect the owner of that same device outside the container and verify the permissions looks weird.