[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#946242: fatal: privsep_preauth: preauth child terminated by signal 31



Ian Jackson (CCed) just ran into this and we debugged it together on
IRC.  This turns out to be a variant of https://bugs.debian.org/941663
that only affects certain architectures, because glibc implements
shmget/shmat/shmdt using the ipc syscall on certain architectures.  For
example, shmget is:

  int
  shmget (key_t key, size_t size, int shmflg)
  {
  #ifdef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
    return INLINE_SYSCALL_CALL (shmget, key, size, shmflg, NULL);
  #else
    return INLINE_SYSCALL_CALL (ipc, IPCOP_shmget, key, size, shmflg, NULL);
  #endif
  }

And:

  sysdeps/unix/sysv/linux/i386/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/kernel-features.h:#define __ASSUME_DIRECT_SYSVIPC_SYSCALLS      1
  sysdeps/unix/sysv/linux/m68k/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/mips/kernel-features.h:# undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/powerpc/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/s390/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/sh/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS
  sysdeps/unix/sysv/linux/sparc/kernel-features.h:#undef __ASSUME_DIRECT_SYSVIPC_SYSCALLS

I think a fix for this that applies to buster would be:

diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
index e8f31555e..121760418 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
@@ -134,6 +134,9 @@ static const struct sock_filter preauth_insns[] = {
 #ifdef __NR_fstat64
 	SC_DENY(__NR_fstat64, EACCES),
 #endif
+#ifdef __NR_ipc
+	SC_DENY(__NR_ipc, EACCES),
+#endif
 #ifdef __NR_open
 	SC_DENY(__NR_open, EACCES),
 #endif

I have some other things to do this weekend, but I'll chase this up with
upstream and arrange for this to get into appropriate Debian packages.

-- 
Colin Watson                                       [cjwatson@debian.org]


Reply to: