gdb: linux-namespaces: enter user namespace when appropriate

gdb: linux-namespaces: enter user namespace when appropriate

The use of user namespaces is required for normal users to use mount
namespaces.  Consider trying this as an unprivileged user:

  $ unshare --mount /bin/true
  unshare: unshare failed: Operation not permitted

The problem here is that an unprivileged user doesn't have the
required permissions to create a new mount namespace.  If, instead, we
do this:

  $ unshare --mount --map-root-user /bin/true

then this will succeed.  The new option causes unshare to create a
user namespace in which the unprivileged user is mapped to UID/GID 0,
and so gains all privileges (inside the namespace), the user is then
able to create the mount namespace as required.

So, how does this relate to GDB?

When a user attaches to a process running in a separate mount
namespace, GDB makes use of a separate helper process (see
linux_mntns_get_helper in nat/linux-namespaces.c), which will then use
the `setns` function to enter (or try to enter) the mount namespace of
the process GDB is attaching too.  The helper process will then handle
file I/O requests received from GDB, and return the results back to
GDB, this allows GDB to access files within the mount namespace.

The problem here is that, switching to a mount namespace requires that
a process hold CAP_SYS_CHROOT and CAP_SYS_ADMIN capabilities within
its user namespace (actually it's a little more complex, see 'man 2
setns').  Assuming GDB is running as an unprivileged user, then GDB
will not have the required permissions.

However, if GDB enters the user namespace that the `unshare` process
created, then the current user will be mapped to UID/GID 0, and will
have the required permissions.

And so, this patch extends linux_mntns_access_fs (in
nat/linux-namespace.c) to first try and switch to the user namespace
of the inferior before trying to switch to the mount namespace.  If
the inferior does have a user namespace, and does have elevated
privileges within that namespace, then this first switch by GDB will
mean that the second step, into the mount namespace, will succeed.

If there is no user namespace, or the inferior doesn't have elevated
privileges within the user namespace, then the switch into the mount
namespace will fail, just as it currently does, and the user will need
to give elevated privileges to GDB via some other mechanism (e.g. run
as root).

This work was originally posted here:

  https://inbox.sourceware.org/gdb-patches/20230321120126.1418012-1-benjamin@sipsolutions.net

I (Andrew Burgess) have made some cleanups to the code to comply with
GDB's coding standard, and the test is entirely mine.  This commit
message is also entirely mine -- the original message was very terse
and required the reader to understand how the various namespaces
work and interact.  The above is my attempt to document what I now
understand about the problem being fixed.

I've left the original author in place as the core of the GDB change
itself is largely as originally presented, but any inaccuracies in the
commit message, or problems with the test, are all mine.

Co-Authored-by: Andrew Burgess <aburgess@redhat.com>