Describe the bug
If a user is a member of any group that grants access to device nodes in folders that have 750 permissions, all toolboxes can no longer be entered.

For example when VirtualBox is installed, the /dev/vboxusb/* device nodes are created with 750 permissions on both the folder and the files, and they're owned by the vboxusers group (this behavior is consistent with standards for device node permissions, and is like the /dev/ttyUSB* nodes on Fedora systems). Toolbox maps the entire /dev into the container, which uses the user permissions from outside the container to map all visible files into the container. The crun mapping of sub-folders uses the permissions inside the container namespaces to create a matching folder however. This causes an error because the folder has permissions granted only via an unmapped group.

TL;DR
Blanket mapping of /dev into the container without also mapping all the user's groups breaks in very common conditions.

Steps how to reproduce the behaviour

1. Create device node in a folder with 750 permissions, owned by a group the user is part of but not by the user directly.
   1. sudo mkdir -Z -m 750 /dev/testFolder
   2. sudo mkdnod -Z -m 750 /dev/testFolder/testNode b 7 30 (loop device 30)
   3. sudo chown -R root:dialout /dev/testFolder (dialout used for convenience rather than
      creating a new group)
   4. groups, and confirm user is part of dialout group
   5. ls /dev/testFolder, confirm the user can see the files using the dialout group permissions
2. toolbox create
3. toolbox enter

Expected behaviour
Toolbox is entered successfully.

Actual behaviour
Error, unable to enter toolbox.

Error: unable to start container XXXX: crun: mkdir `/dev/testFolder`: Permission denied: OCI permission denied

Screenshots

N/A

Output of toolbox --version (v0.0.90+)

toolbox version 0.0.99.4

Toolbox package info (rpm -q toolbox)

toolbox version 0.0.99.4

Output of podman version

Client:       Podman Engine
Version:      4.6.0
API Version:  4.6.0
Go Version:   go1.20.6
Built:        Fri Jul 21 08:23:26 2023
OS/Arch:      linux/amd64

Podman package info (rpm -q podman)

podman-4.6.0-1.fc38.x86_64

Info about your OS
Fedora Kinoite 38

Additional context

The issue becomes immediately very obvious if you install VirtualBox. This creates /dev/vboxusb/* USB proxy device nodes, where the /dev/vboxusb and all contents are owned by the vboxusers group. If the user isn't part of the vboxusers group, toolbox works because the folder doesn't appear to be present under the user permissions. But if the user is a member of the group (as can be expected), the folder can be listed from outside the container, but the permissions for interacting with it inside the container namespace aren't available to crun.

The only viable solutions are:

1. Stop mounting /dev as a whole into the container and instead iterate over all device nodes found recursively from outside the container, filtered down to the ones owned directly by the user or with 755 permissions.
2. Use --group-add keep-groups and have toolbox init-container inside the container create the necessary matching groups/gids that are added to the user in the container.
3. Allow a an option to toolbox create, --keep-group={group_name}, that can list multiple groups that should be mapped from the host user into the container. Allow a default list to be specified in the toolbox.conf.

The second option is obviously much better than 1 since it solves a number of other complaints (e.g. /dev/ttyUSB* access), but has the negative effect that the list of group names to gids from the user outside the container must be replicated inside the container, and traceability of what those were must be kept inside the container so if a user is removed from a group they will also be removed from the group inside the container.

Option 3 is probably the best though, since it allows the current existing behavior as-is, but also allows users to specifically pass thru certain group permissions. It would suffer from the same complexities as option 2 in terms of implementation though, and would add the need to parse extra command-line options and config file fields.