1. Proposed title of this feature request

Files downloaded by an ADD directive in a Dockerfile should have same behavior regarding permissions in OCP builds than building the image with podman/docker

2. What is the nature and description of the request?

If an "ADD" directive is added to a Dockerfile, and then this Dockerfile is used to build an image either with podman/docker it works as expected without any special privilege, e.g:

Dockerfile:

```
FROM registry.access.redhat.com/ubi8/python-38:latest

RUN id; umask

ADD https://github.com/netbox-community/netbox/archive/v2.9.9.tar.gz .

RUN ls -ln v2.9.9.tar.gz

RUN set -ex; \
tar -xf v2.9.9.tar.gz; \
ln -sr netbox-2.9.9 netbox-current
```

Build:

```
$ podman build . -t netbox
STEP 1: FROM registry.access.redhat.com/ubi8/python-38:latest
STEP 2: RUN id; umask
--> Using cache d898275aa593ec0cdc905b050e2bfb61a17de3b89646eafd1df8071e03180a68
STEP 3: ADD https://github.com/netbox-community/netbox/archive/v2.9.9.tar.gz .
--> Using cache beb741ff8413cb4a0b2b39970c680259cbba545cff694d1652fc6edd899f5f79
STEP 4: RUN ls -ln v2.9.9.tar.gz
rw------. 1 1001 0 5801532 Nov 13 11:33 v2.9.9.tar.gz
--> 0f0b5b6b04f
STEP 5: RUN set -ex; tar -xf v2.9.9.tar.gz; ln -sr netbox-2.9.9 netbox-current
+ tar -xf v2.9.9.tar.gz
+ ln -sr netbox-2.9.9 netbox-current
--> 60b2b515d85
```

However, if same Dockerfile is used within OCP then build fails as only root seems to be able to read the file downloaded by the "ADD" directive. Whereas with podman, the file is owned by the UID that is in effect when the "ADD" directive is processed (1001, inherited from the `ubi8/python-38` container image).

3. Why does the customer need this? (List the business requirements here)

To have a consistent behavior between local image builds and the ones performed within OCP.

4. List any affected packages or components.

OCP builds.