View Issue Details

Jump to NotesJump to History
IDProjectCategoryView StatusDate SubmittedLast Update
0006947Kali LinuxGeneral Bugpublic2020-12-25 01:252022-03-25 13:58
ReporterL1ghtn1ng Assigned Tosbrun  
PrioritynormalSeverityminorReproducibilityalways
Status assignedResolutionopen 
Summary0006947: Redis-Server packaging issues
Description

Dec 24 22:02:58 kali systemd[1]: Stopped Advanced key-value store.
Dec 24 22:21:58 kali systemd[1]: Starting Advanced key-value store...
Dec 24 22:21:58 kali systemd[1]: redis-server.service: Can't open PID file /run/redis/redis-server.pid (yet?) after start: Operation not permitted

This seems to be due to the unit file from what has been set in it, this is what I get on my system but on another system it fails to start when using systemctl start redis-server and this is what it spits out in the journal

Dec 24 18:59:11 kali redis-server[5696]: FATAL CONFIG FILE ERROR (Redis 6.0.9)
Dec 24 18:59:11 kali redis-server[5696]: Reading the configuration file, at line 260
Dec 24 18:59:11 kali redis-server[5696]: >>> 'logfile /var/log/redis/redis-server.log'
Dec 24 18:59:11 kali redis-server[5696]: Can't open the log file: Permission denied

The other odd thing is that if you do redis-server /etc/redis/redis.conf it works fine just not with the unit file when doing systemctl start redis-server

Activities

JmbFountain

JmbFountain

2021-12-28 14:48

reporter   ~0015573

This bug also breaks openvas
JmbFountain

JmbFountain

2021-12-28 15:14

reporter   ~0015575

This is likely an issue with the systemd unit config shipped by default. Redis will start after setting "ProtectSystem=False" or correcting the ReadWriteDirectories-Entries
JmbFountain

JmbFountain

2021-12-29 08:24

reporter   ~0015577

Upstream issue: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1002738

For me the workaround was to set "ProtectSystem=strict" and to comment out "ReadOnlyDirectories=/".

This seems to also be the way systemd recommends protecting the root directory: (manpage systemd.exec)

   ProtectSystem=
       Takes a boolean argument or the special values "full" or "strict".
       If true, mounts the /usr/ and the boot loader directories (/boot
       and /efi) read-only for processes invoked by this unit. If set to
       "full", the /etc/ directory is mounted read-only, too. If set to
       "strict" the entire file system hierarchy is mounted read-only,
       except for the API file system subtrees /dev/, /proc/ and /sys/
       (protect these directories using PrivateDevices=,
       ProtectKernelTunables=, ProtectControlGroups=). This setting
       ensures that any modification of the vendor-supplied operating
       system (and optionally its configuration, and local mounts) is
       prohibited for the service. It is recommended to enable this
       setting for all long-running services, unless they are involved
       with system updates or need to modify the operating system in other
       ways. If this option is used, ReadWritePaths= may be used to
       exclude specific directories from being made read-only. This
       setting is implied if DynamicUser= is set. This setting cannot
       ensure protection in all cases. In general it has the same
       limitations as ReadOnlyPaths=, see below. Defaults to off.

Issue History

Date Modified Username Field Change
2020-12-25 01:25 L1ghtn1ng New Issue
2021-06-30 08:49 g0tmi1k Priority high => normal
2021-12-28 14:48 JmbFountain Note Added: 0015573
2021-12-28 15:14 JmbFountain Note Added: 0015575
2021-12-29 08:24 JmbFountain Note Added: 0015577
2021-12-29 13:17 sbrun Assigned To => sbrun
2021-12-29 13:17 sbrun Status new => assigned
2022-03-25 13:57 g0tmi1k Severity crash => feature
2022-03-25 13:58 g0tmi1k Severity feature => minor