[Bug 2813] sshd fails to start in user namespaces when the gid for tty is not mapped

[bugzilla-daemon at bugzilla.mindrot.org]

https://bugzilla.mindrot.org/show_bug.cgi?id=2813

--- Comment #7 from Oliver Freyermuth <o.freyermuth at googlemail.com> ---
(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?

-- 
You are receiving this mail because:
You are watching someone on the CC list of the bug.
You are watching the assignee of the bug.