Description of problem: Attempting to log in to an arm machine via ssh fails with: ssh pwhalen.122.94 Connection closed by 192.168.122.94 port 22 On the host: Jan 29 21:11:51 localhost.localdomain audit[3318]: SECCOMP auid=4294967295 uid=74 gid=74 ses=4294967295 subj=system_u:system_r:sshd_net_t:s0-s0:c0.c1023 pid=3318 comm="sshd" exe="/usr/sbin/sshd" sig=31 arch=40000028 syscall=403 compat=0 ip=0xb69007b4 code=0x0 Jan 29 21:11:51 localhost.localdomain audit[3318]: ANOM_ABEND auid=4294967295 uid=74 gid=74 ses=4294967295 subj=system_u:system_r:sshd_net_t:s0-s0:c0.c1023 pid=3318 comm="sshd" exe="/usr/sbin/sshd" sig=31 res=1 Syscall 403 is clock_gettime64, from the glibc-2.30.9000-29.fc32 changelog 'Enable vDSO clock_gettime64 for arm'. Downgrading to glibc-2.30.9000-28.fc32 allowed for successful login via ssh. Version-Release number of selected component (if applicable): openssh-8.1p1-3.fc32.armv7hl libseccomp-2.4.2-2.fc32.armv7hl glibc-2.30.9000-31.fc32.armv7hl
I think this is related to work around the year 2038 bug. I also don't think it's specific to ssh as I'm seeing similar things in other cases: EG reboot: # reboot Assertion 'clock_gettime(map_clock_id(clock_id), &ts) == 0' failed at src/basic/time-util.c:53, function now(). Aborting. Aborted (core dumped)
Also not sure if the problem will be fixed when the mass rebuild is merged as everything will be rebuilt against the newer glibc
The seccomp filter in openssh needs to be adjusted to include the time64 system calls or fail them with ENOSYS (the special error code that indicates lack of kernel support).
(In reply to Florian Weimer from comment #3) > The seccomp filter in openssh needs to be adjusted to include the time64 > system calls or fail them with ENOSYS (the special error code that indicates > lack of kernel support). What about reboot not working then?
(In reply to Peter Robinson from comment #4) > (In reply to Florian Weimer from comment #3) > > The seccomp filter in openssh needs to be adjusted to include the time64 > > system calls or fail them with ENOSYS (the special error code that indicates > > lack of kernel support). > > What about reboot not working then? This is probably the consequence of systemd failing unknown system calls with EPERM instead of ENOSYS in its sandbox. The systemd developers are aware, but have declined to fix this.
Please, try the following dist git patch. I can try to provide you a scratch build, before I will update it in rawhide. diff --git a/openssh-8.1p1-seccomp-nanosleep.patch b/openssh-8.1p1-seccomp-nanosleep.patch index 87f4bd4..a7a16fd 100644 --- a/openssh-8.1p1-seccomp-nanosleep.patch +++ b/openssh-8.1p1-seccomp-nanosleep.patch @@ -29,12 +29,15 @@ diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c index be239767..3ef30c9d 100644 --- a/sandbox-seccomp-filter.c +++ b/sandbox-seccomp-filter.c -@@ -245,6 +245,9 @@ static const struct sock_filter preauth_insns[] = { +@@ -245,6 +245,12 @@ static const struct sock_filter preauth_insns[] = { #ifdef __NR_clock_nanosleep SC_ALLOW(__NR_clock_nanosleep), #endif +#ifdef __NR_clock_nanosleep_time64 + SC_ALLOW(__NR_clock_nanosleep_time64), ++#endif ++#ifdef __NR_clock_gettime64 ++ SC_ALLOW(__NR_clock_gettime64), +#endif #ifdef __NR__newselect SC_ALLOW(__NR__newselect),
Proposing as a blocker for beta, this bug severely inhibits the ability to complete tests on a remote system.
I did not get any feedback on the patch so I am pushing it as it is (similarly as it is now in upstream). The rawhide package is built. If it will not address the issue, please reopen.
Apologies, I didnt get a chance to verify yesterday. New build fixes the issue, many thanks.
We were overtaken by events, but for the record: Discussed at 2020-02-03 blocker review meeting: https://meetbot-raw.fedoraproject.org/fedora-blocker-review/2020-02-03/f32-blocker-review.2020-02-03-17.13.html . Accepted as a Beta blocker under the "Bug hinders execution of required Beta test plans or dramatically reduces test coverage" qualification at https://fedoraproject.org/wiki/Fedora_32_Beta_Release_Criteria#Beta_Blocker_Bugs (we rarely use that, preferring the explicit release criteria, but it seemed highly appropriate in this case; doing ARM testing without ssh access is painful).