Created attachment 3105 [details] Patch to support user namespaces In unprivileged user namespaces (c.f. https://lwn.net/Articles/532593/ ), the user's uid / gid pair can be mapped to a single uid / gid pair in the namespace. User namespaces are in heavy use for any unprivileged linux container implementation (runC's rootless containers, singularity's containers in non-setuid mode, charliecloud containers, docker with user namespace support enabled etc.). Typically, the uid / gid of the user or 0 / 0 are used, hence the gid of the tty group will not be mapped. Any unmapped uid and gid will be mapped to the "overflow uid / gid" by the kernel (0xFFFE = 65534). This causes sshd to fail when trying to chown the /dev/pts/xx device. The only workaround would be (for the user) to map his / her own group id to the tty gid, which rather is a dirty hack. The attached patch adds an exception in the case chown fails and the pts device is owned by the matching uid and the overflow gid. In this case, only a debug message is shown, but execution continues.
This looks like a configuration problem. Why not arrange for the namespace to map the tty gid too?
That's not possible. See: http://man7.org/linux/man-pages/man7/user_namespaces.7.html In short, as already mentioned, in a user-namespace, one can only map his / her own effective uid / gid from outside the namespace to a single uid / gid paid inside the namespace. Mapping of other uids / gids required privileges (CAP_SETUID / CAP_SETGID) in the parent namespace, which users do not have. So there is nothing to configure, sadly.
Sorry to bump this. Are there any new ideas about this? Are there any thoughts about the patch?
Do these containers use a chroot or equivalent? If so, removing "tty" from the groups file inside the chroot will cause sshd to use the user's gid which sounds like what you want: /* Determine the group to make the owner of the tty. */ grp = getgrnam("tty"); gid = (grp != NULL) ? grp->gr_gid : pw->pw_gid;
This does indeed sound like a valid dirty hack that could be used for all self-made containers! I'll give it a spin in the next days. It does not scale, though: This would mean all containers out there (for example the hundreds of thousands on DockerHub) would need that hack to the group-file. This fallback, in my opinion, makes things even more strange: Why only fallback when tty is not in the groups file, and not fallback always? Is there any reason to care if the pty belongs to a group named "tty" explicitly (and only if that exists) instead of just caring for the actual permissions?
(In reply to Oliver Freyermuth from comment #5) > This does indeed sound like a valid dirty hack that could be used > for all self-made containers! I'll give it a spin in the next days. > > It does not scale, though: This would mean all containers out there > (for example the hundreds of thousands on DockerHub) would need that > hack to the group-file. If your system is violating POSIX by making chown() do strange things or stat() lie then any workarounds that are required are on you. OpenSSH is deployed on a lot of systems on many platforms and configurations. Unix pty handling is already weird enough without adding hacks for such cases. > This fallback, in my opinion, makes things even more strange: Why > only fallback when tty is not in the groups file, and not fallback > always? Is there any reason to care if the pty belongs to a group > named "tty" explicitly (and only if that exists) instead of just > caring for the actual permissions? Yes, eg on some systems tools such as write(1) rely on being able to open the tty device by virtue of being setgid tty: $ uname -sr; ls -l `which write` Linux 4.18.10-200.fc28.x86_64 -rwxr-sr-x 1 root tty 20328 Jul 16 21:56 /usr/bin/write
(In reply to Darren Tucker from comment #6) > If your system is violating POSIX by making chown() do strange > things or stat() lie then any workarounds that are required are on > you. I'm talking about a standard Linux' kernel behaviour here, not an obscure system. See my documentation link above. It seems you are also using a pretty modern Linux, so to experience that, just run, as normal user: unshare -U -r -m /bin/bash This only does some syscalls, afterwards check out: ls -lrta /dev/pts/ Containers (docker, runc, singularity, charliecloud, whatever the runtime is called) make use of just that. It's essentially chroot without root, which relies on help from the kernel. Since you seem to be running Fedora: This technology is heavily pushed exactly by Fedora and RedHat. Their tool is called podman, and it is a feature announced with Fedora 28. On a related note, I tested that hacking /etc/group works. The main issue, as I stated, is that even if the group "tty" is not mapped into the namespace, sshd relies on it - as soon as it is put into /etc/group. > Yes, eg on some systems tools such as write(1) rely on being able to > open the tty device by virtue of being setgid tty: > > $ uname -sr; ls -l `which write` > Linux 4.18.10-200.fc28.x86_64 > -rwxr-sr-x 1 root tty 20328 Jul 16 21:56 /usr/bin/write Does POSIX state it needs to be setgid tty within the same namespace the user is working in, and that an application needs to check the group is called tty and devices are owned by that group, instead of relying on the kernel?
AFAICT POSIX doesn't have any notion of namespaces at all. Anyway, when you configure your container's behaviour to not match what's inside the container it doesn't work. When they match, it works. Sorry, but I don't think this warrants carrying a system-specific hack.
closing resolved bugs as of 8.6p1 release