Functionality of the --dev-flag/can't enter bwrapped namespace due to nesting (opt_needs_devpts)

[flxmr]

So, I've been using bubblewrap to isolate environments and I've been using the "--dev" option to populate /dev in the mount namespace. Unfortunately I can't enter the created namespaces with nsenter (as a normal user); I think this is related to the --dev-option binding stdout of the process to /dev/stdout. What are the considerations of this when comparing it to setting up a tmpfs and linking the relevant dev (null/random/...)?

Considerations are: terminal won't work ;).

This seems really weird. Removing all the code in the case-statement for "SETUP_MOUNT_DEV" also does not work.

[flxmr]

So, I had another look at the code (not really proficient with C/gdb, but enough for printf-debugging), and it turned out the problem does not lie in the "SETUP_MOUNT_DEV"-portion (which is doing nothing but but in the "opt_needs_devpts"-bool set with the "--dev"-CLI option.

For my case (non-setuid-binary straight from git, so user-namespaces all the way through), this means, that this portion of code is executed https://github.com/containers/bubblewrap/blob/93047df6052034989a576de55a6fe2cce05f3524/bubblewrap.c#L2444-L2464 Thus during the following chroot-procedure bwrap is root (uid == 0) in the target namespace, independent of what was passed as "opt_sandbox_uid", when the "--dev"-flag is passed (and opt_needs_devpts is set). Then chrooting everything, bwrap drops into another user-namespace, because the uid in the current namespace is not the same as opt_sandbox_uid: https://github.com/containers/bubblewrap/blob/93047df6052034989a576de55a6fe2cce05f3524/bubblewrap.c#L2599-L2613 (mapping the actual sandbox user to uid=0 of the "outer" user sandbox).

Apparently this nesting of usernamespaces then screws up things sufficiently that you can't use nsenter anymore to conveniently enter the namespace as non-root (and as it only wraps setns, I'm not sure, how you could actually enter the namespace).

However I've found that just dropping the switch to root in the container isn't necessary at all with my setup and it works fine, when removing the following portion of code, so this hack seems only necessary on specific systems? https://github.com/containers/bubblewrap/blob/93047df6052034989a576de55a6fe2cce05f3524/bubblewrap.c#L2451-L2458

so now the tl;dr:

• what are the security-implications of setting up devpts with the normal user in the container (if any); are there any limitations otherwise (I can start tmux just fine and this seems to be the most complex usage of a terminal I'd ever need)?
• basically I can work around that by running as root in the container. As I'm not remapping anything via /etc/subid, this means ...