Bug#903603: ssh upgrade breaks in some openvz container
Following up to this, I was running testing under this same openvz kernel, and I noticed that su displayed a similar message about setrlimit, and failed. So perhaps the problem is really in PAM? Or multiple things just don't work with that openvz kernel. -- see shy jo signature.asc Description: PGP signature
Bug#903603: ssh upgrade breaks in some openvz container
On Mon, Jul 30, 2018 at 04:50:42PM -0400, Joey Hess wrote:
> I don't get the impression the hosting provider is going to be of any help;
> they're of the bagain basement variety and are struggling with the concept
> that a newer kernel is also needed for eg, running systemd.
Oh dear.
> Based on uname output of "2.6.32-openvz-042stab127.2-amd64 #1 SMP Thu Jan 4
> 16:43:57 MSK 2018"
> the kernel binary comes directly from openvz.org so you seem to have
> the matching source.
>
> Interestingly, running as root, strace bash -c 'ulimit -Sn 0 -Hn 0' results
> in:
>
> setrlimit(RLIMIT_NOFILE, {rlim_cur=0, rlim_max=0}) = 0
>
> So that kernel doesn't generally fail when called with those parameters.
> It seems like something else that ssh does may be leading to the EINVAL?
Hmm. That's kind of startling, since it hasn't really done that much
else by that point (at least not in the sandbox child). Can you start
up sshd (maybe on a spare port) under strace -f and see if that reveals
any oddities?
Failing that, is there any way I could get root access to an environment
where it's possible to reproduce the bug so that I can experiment? My
efforts at zen-debugging this aren't really getting anywhere fast.
Thanks,
--
Colin Watson [cjwat...@debian.org]
Bug#903603: ssh upgrade breaks in some openvz container
Colin Watson wrote:
> I grabbed the kernel source in question from
> https://wiki.openvz.org/Download/kernel/rhel6/042stab127.2 (there are a
> few newer versions, but it's apparently fairly recent and none of the
> newer ones mention anything about resource limits). I can't see
> anything in the implementation of setrlimit that could plausibly make it
> return EINVAL here, unless, I don't know, there's some silent type
> mismatch or something. What architecture is the container?
x86_64
> Do you know of a good support/bug contact for OpenVZ? I'm not familiar
> with it at all, and I think we need some idea of what the problem is
> there before we even have a clue about what a reasonable workaround in
> OpenSSH might be. (Disabling the sandbox doesn't count as reasonable
> here, at least not long-term.) Have you asked the hosting provider if
> they know what might be going on, or if they have an upstream they could
> ask? Presumably somebody maintains this kernel.
I don't get the impression the hosting provider is going to be of any help;
they're of the bagain basement variety and are struggling with the concept
that a newer kernel is also needed for eg, running systemd.
Based on uname output of "2.6.32-openvz-042stab127.2-amd64 #1 SMP Thu Jan 4
16:43:57 MSK 2018"
the kernel binary comes directly from openvz.org so you seem to have
the matching source.
Interestingly, running as root, strace bash -c 'ulimit -Sn 0 -Hn 0' results in:
setrlimit(RLIMIT_NOFILE, {rlim_cur=0, rlim_max=0}) = 0
So that kernel doesn't generally fail when called with those parameters.
It seems like something else that ssh does may be leading to the EINVAL?
--
see shy jo
signature.asc
Description: PGP signature
Bug#903603: ssh upgrade breaks in some openvz container
On Sun, Jul 22, 2018 at 11:40:40AM +0100, Colin Watson wrote: > Do you know of a good support/bug contact for OpenVZ? I'm not familiar > with it at all, and I think we need some idea of what the problem is > there before we even have a clue about what a reasonable workaround in > OpenSSH might be. (Disabling the sandbox doesn't count as reasonable > here, at least not long-term.) Have you asked the hosting provider if > they know what might be going on, or if they have an upstream they could > ask? Presumably somebody maintains this kernel. I grabbed the kernel source in question from https://wiki.openvz.org/Download/kernel/rhel6/042stab127.2 (there are a few newer versions, but it's apparently fairly recent and none of the newer ones mention anything about resource limits). I can't see anything in the implementation of setrlimit that could plausibly make it return EINVAL here, unless, I don't know, there's some silent type mismatch or something. What architecture is the container? I think you do need to ask OpenVZ people about this first, though. I'm not closing this bug since obviously it's bad for sshd's sandbox to stop working, but we need somebody who knows the OpenVZ kernel to tell us what a decent workaround might be (and maybe it's just a straight-up OpenVZ kernel bug and doesn't require a change in OpenSSH at all). -- Colin Watson [cjwat...@debian.org]
Bug#903603: ssh upgrade breaks in some openvz container
On Wed, Jul 11, 2018 at 02:58:00PM -0400, Joey Hess wrote:
> After upgrading some openvz container at a hosting provider to unstable,
> ssh stopped working; incoming connections closed before password prompt.
>
> In auth.log, there was this:
>
> ssh_sandbox_child: setrlimit(RLIMIT_NOFILE, { 0, 0 }): Invalid argument
> [preauth]
>
> Seems like there is no way to disable the sandbox any more,
> and so this may cause problems for openvz users.
>
> That openvz was running kernel version 2.6.32-openvz-042stab127.2. I
> have avoided openvz until now, so I don't know if such an outdated
> kernel is typical of openvz hosting providers.
>
> I can't find mention of RLIMIT_NOFILE not being supported in that old
> kernel version though (even with 0, 0), so it may not be the fault of an
> outdated kernel, but a limitation of openvz generally that RLIMIT_NOFILE
> doesn't work.
Yeah, I don't see why reducing the limits would be a problem even in
such an old kernel.
Do you know of a good support/bug contact for OpenVZ? I'm not familiar
with it at all, and I think we need some idea of what the problem is
there before we even have a clue about what a reasonable workaround in
OpenSSH might be. (Disabling the sandbox doesn't count as reasonable
here, at least not long-term.) Have you asked the hosting provider if
they know what might be going on, or if they have an upstream they could
ask? Presumably somebody maintains this kernel.
Thanks,
--
Colin Watson [cjwat...@debian.org]
Bug#903603: ssh upgrade breaks in some openvz container
Package: openssh-server
Version: 1:7.7p1-2
Severity: normal
After upgrading some openvz container at a hosting provider to unstable,
ssh stopped working; incoming connections closed before password prompt.
In auth.log, there was this:
ssh_sandbox_child: setrlimit(RLIMIT_NOFILE, { 0, 0 }): Invalid argument
[preauth]
Seems like there is no way to disable the sandbox any more,
and so this may cause problems for openvz users.
That openvz was running kernel version 2.6.32-openvz-042stab127.2. I
have avoided openvz until now, so I don't know if such an outdated
kernel is typical of openvz hosting providers.
I can't find mention of RLIMIT_NOFILE not being supported in that old
kernel version though (even with 0, 0), so it may not be the fault of an
outdated kernel, but a limitation of openvz generally that RLIMIT_NOFILE
doesn't work.
--
see shy jo
signature.asc
Description: PGP signature
