Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
Marc Ballarin wrote: > I guess the proper thing here, would simply be to document this in the > release notes. Perhaps in a general form, as there might be more > packages affected[1] and more users might run ancient or strange kernels > for whatever reason (Hosting environments, bad ARM devices that need > vendor kernels, ...). Isn't that generally known though? If I run an ancient kernel, it seems unlikely that a recent systemd will work, parallel to udev, X, etc. etc. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
Am 28.05.2017 um 11:13 schrieb Chris Lamb: Urgh. This makes it very difficult for me to justify this change, alas. :( It sounds like you want to get out of this old container to be honest and not spend your time and effort trying to work around all its problems and issues. (You also *want* the hardening!) Well, there is obviously a limit on how far broken platforms can and should be supported ;-) I guess the proper thing here, would simply be to document this in the release notes. Perhaps in a general form, as there might be more packages affected[1] and more users might run ancient or strange kernels for whatever reason (Hosting environments, bad ARM devices that need vendor kernels, ...). In any case, if someone else runs into this, the attached drop-in, placed into /etc/systemd/system/redis-server.service.d/override.conf, can work around those platform limitations. This will obviously remove the "PrivateDevices" restriction from redis-server. Regards, Marc [1] phpsessionclean.service from php-common fails on ProtectSystem=true [Service] # needed to work on kernels < 3.5 that have seccomp enabled but lack "no_new_privs" PrivateDevices=no # needed to work on kernels that have some different behaviour in symlink handling # (not sure exactly what and why) ReadWriteDirectories= ReadWriteDirectories=-/var/lib/redis ReadWriteDirectories=-/var/log/redis ReadWriteDirectories=-/run/redis ReadWriteDirectories=-/etc/redis
Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
tags 863477 + unreproducible severity 863477 minor thanks > Unfortunately, this is a provider kernel. I don't know anything about > its patches or configuration. I don't even have /dev/kmsg or any kernel > related file inside the container. Urgh. This makes it very difficult for me to justify this change, alas. :( It sounds like you want to get out of this old container to be honest and not spend your time and effort trying to work around all its problems and issues. (You also *want* the hardening!) Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
Am 27.05.2017 um 20:13 schrieb Chris Lamb: Can you elaborate more on exactly what this kernel is? eg. what version, what makes Virtuozzo special here, etc. etc. Trying to work out the scope of the problem. Unfortunately, this is a provider kernel. I don't know anything about its patches or configuration. I don't even have /dev/kmsg or any kernel related file inside the container. The full version string is: 3.2.41-042stab120.5 #1 SMP Tue Oct 25 22:31:12 MSK 2016 x86_64 GNU/Linux, but I don't think that tells us more than that it is ancient and probably heavily patched. I'm at a loss how to debug the namespace setup: Strace on PID 1 does not work, most likely due to some hardening (or it being already traced from the outside): # strace -p 1 strace: attach: ptrace(PTRACE_ATTACH, 1): Operation not permitted strace in the unit file is already too late. Arguably, the best solution - at least for myself - would be, to get rid of this container. Nevertheless, the fix to redis-server.service seems straightforward, even if it is just a workaround for a deeper issue. Can you comment on whether switching it to /run will work on all systems? I wouldn't want to push this into Stretch without being very confident. It seems unit files currently pick /run vs. /var/run at will. Systemd's own units always use /run, as does LVM, Syslog or ALSA. Samba, CUPS and DBUs use /var/run. /run should always work, according to https://wiki.debian.org/ReleaseGoals/RunDirectory#How_to_transition_from_.2Fvar.2Frun_to_.2Frun_and_.2Fvar.2Flock_to_.2Frun.2Flock.3F Some additional things I discovered: 1. With the patched unit file there is a follow-up graceful failure: redis-server.service: SECCOMP features not detected in the kernel, skipping PrivateDevices= 2. Trying redis-server from Stretch on Wheezy's kernel 3.2.88-1 results in a failure with "status=227/NO_NEW_PRIVILEGES". This can be worked around by setting |PrivateDevices=no. I assume this kernel - unlike the hosted one - knows seccomp, but lacks "no_new_privs", and that this combination causes a non-graceful failure. |3. Another unit, mphpsessionclean.service, also has namespace issues: mphpsessionclean.service: Failed at step NAMESPACE spawning /usr/lib/php/sessionclean: Value too large for defined data type
Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
Hi Marc, > I upgraded a hosted Virtuozzo container from Jessie to Stretch. After the > upgrade, redis-server fails to start: [..] > 3. An ancient kernel and/or Virtuozzo is in use. I could not reproduce > it on a system running the default Debian kernel 4.9. Can you elaborate more on exactly what this kernel is? eg. what version, what makes Virtuozzo special here, etc. etc. Trying to work out the scope of the problem. > Nevertheless, the fix to redis-server.service seems straightforward, > even if it is just a workaround for a deeper issue. Can you comment on whether switching it to /run will work on all systems? I wouldn't want to push this into Stretch without being very confident. Regards, -- ,''`. : :' : Chris Lamb `. `'` la...@debian.org / chris-lamb.co.uk `-
Bug#863477: redis-server: Systemd unit namespace setup can fail on ancient/strange kernels
Package: redis-server Version: 3:3.2.9-1 Severity: normal Dear Maintainer, I upgraded a hosted Virtuozzo container from Jessie to Stretch. After the upgrade, redis-server fails to start: May 27 12:47:44 run-parts[3349]: redis-server.service: Failed at step NAMESPACE spawning /bin/run-parts: Too many levels of symbolic links It seems, this happens, if all of the following conditions are met: 1. redis-server.service contains ReadWriteDirectories=-/var/run/redis 2. /var/run is a symlink to /run 3. An ancient kernel and/or Virtuozzo is in use. I could not reproduce it on a system running the default Debian kernel 4.9. I could fix it by changing ReadWriteDirectories=-/var/run/redis to ReadWriteDirectories=-/run/redis AFAICT, redis-server is the only package I installed that uses those namespacing features. So this might actually be a Systemd bug or a bad Systemd/kernel version interaction. Nevertheless, the fix to redis-server.service seems straightforward, even if it is just a workaround for a deeper issue. Regards, Marc -- System Information: Debian Release: 9.0 APT prefers testing APT policy: (500, 'testing') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 3.2.41-042stab120.5 (SMP w/2 CPU cores) Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages redis-server depends on: ii adduser 3.115 ii init-system-helpers 1.48 ii libc62.24-10 ii libjemalloc1 3.6.0-9.1 ii lsb-base 9.20161125 ii redis-tools 3:3.2.9-1 ii systemd 232-23 redis-server recommends no packages. redis-server suggests no packages. -- Configuration Files: /etc/redis/redis.conf [Errno 13] Permission denied: '/etc/redis/redis.conf' -- no debconf information
