openssh bugs - Dec 2017 - [Bug 2813] New: sshd fails to start in user namespaces when the gid for tty is not mapped

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

            Bug ID: 2813
           Summary: sshd fails to start in user namespaces when the gid
                    for tty is not mapped
           Product: Portable OpenSSH
           Version: 7.6p1
          Hardware: Other
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P5
         Component: sshd
          Assignee: unassigned-bugs at mindrot.org
          Reporter: o.freyermuth at googlemail.com

Created attachment 3105
  --> https://bugzilla.mindrot.org/attachment.cgi?id=3105&action=edit
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.

-- 
You are receiving this mail because:
You are watching the assignee of the bug.

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |djm at mindrot.org

--- Comment #1 from Damien Miller <djm at mindrot.org> ---
This looks like a configuration problem. Why not arrange for the
namespace to map the tty gid too?

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

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

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

-- 
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.

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

--- Comment #3 from Oliver Freyermuth <o.freyermuth at googlemail.com> ---
Sorry to bump this. Are there any new ideas about this? 
Are there any thoughts about the patch?

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

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dtucker at dtucker.net

--- Comment #4 from Darren Tucker <dtucker at dtucker.net> ---
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;

-- 
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.

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

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

-- 
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.

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

--- Comment #6 from Darren Tucker <dtucker at dtucker.net> ---
(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

-- 
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.

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.

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

Darren Tucker <dtucker at dtucker.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|NEW                         |RESOLVED

--- Comment #8 from Darren Tucker <dtucker at dtucker.net> ---
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.

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

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

Damien Miller <djm at mindrot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #9 from Damien Miller <djm at mindrot.org> ---
closing resolved bugs as of 8.6p1 release

-- 
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.