FS#68556 - coredump on logfile rotate
Attached to Project:
Arch Linux
Opened by Andreas (bjoe2k4) - Saturday, 07 November 2020, 18:48 GMT
Last edited by Pierre Schmitz (Pierre) - Friday, 17 September 2021, 09:59 GMT
Opened by Andreas (bjoe2k4) - Saturday, 07 November 2020, 18:48 GMT
Last edited by Pierre Schmitz (Pierre) - Friday, 17 September 2021, 09:59 GMT
|
Details
Description:
dnscrpyt dumps core during? logfile rotation Additional info: * package version(s) $ uname -rsm Linux 5.9.4-arch1-1 x86_64 $ pacman -Q | grep dnscrypt dnscrypt-proxy 2.0.44-1 * config and/or log files etc. config hanges w.r.t the defaults: log_file = '/var/log/dnscrypt-proxy/dnscrypt-proxy.log' log_files_max_size = 1 * link to upstream bug report, if any Steps to reproduce: * Install packages and and resolve until log file fills up and ready to rotate Nov 07 19:34:36 myhostname audit[1498]: SECCOMP auid=4294967295 uid=62582 gid=62582 ses=4294967295 pid=1498 comm="dnscrypt-proxy" exe="/usr/bin/dnscrypt-proxy" sig=31 arch=c000003e syscall=260 compat=0 ip=0x55c783f5dc9a code=0x80000000 shortly after that and many similar messages dnscrypt-proxy dumps core and is gone. Resolving won't work anymore. $ l total 1.4M drwxr-xr-x 2 62582 62582 4.0K Nov 7 19:34 . drwx------ 3 root root 4.0K Nov 7 19:14 .. -rw-r--r-- 1 62582 62582 1.4M Nov 7 19:21 query-2020-11-07T19-34-36.490.log -rw-r--r-- 1 62582 62582 0 Nov 7 19:34 query-2020-11-07T19-34-36.490.log.gz -rw-r--r-- 1 62582 62582 0 Nov 7 19:34 query.log After commenting out all SystemCall* directives in the service file, rotating files works again. |
This task depends upon
Core was generated by `/usr/bin/dnscrypt-proxy --config /etc/dnscrypt-proxy/dnscrypt-proxy.toml'.
Program terminated with signal SIGSYS, Bad system call.
#0 syscall.Syscall6 () at syscall/asm_linux_amd64.s:50
50 syscall/asm_linux_amd64.s: No such file or directory.
(gdb) bt
#0 syscall.Syscall6 () at syscall/asm_linux_amd64.s:50
#1 0x000055f97774d237 in syscall.Fchownat (dirfd=-100, path=..., uid=62582, gid=62582, flags=0, err=...) at syscall/zsyscall_linux_amd64.go:372
#2 0x000055f9777470ac in syscall.Chown (path=..., uid=62582, gid=62582, err=...) at syscall/syscall_linux.go:31
#3 0x000055f97778785a in os.Chown (name=..., uid=62582, gid=62582, ~r3=...) at os/file_posix.go:104
#4 0x000055f977c670ca in gopkg.in/natefinch/lumberjack%2ev2.chown (name=..., info=..., ~r2=...) at gopkg.in/natefinch/lumberjack.v2@v2.0.0/chown_linux.go:18
#5 0x000055f977c6ba76 in gopkg.in/natefinch/lumberjack%2ev2.compressLogFile (src=..., dst=..., err=...) at gopkg.in/natefinch/lumberjack.v2@v2.0.0/lumberjack.go:480
#6 0x000055f977c69cd5 in gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRunOnce (l=0xc000199200, ~r0=...) at gopkg.in/natefinch/lumberjack.v2@v2.0.0/lumberjack.go:367
#7 0x000055f977c6a2eb in gopkg.in/natefinch/lumberjack%2ev2.(*Logger).millRun (l=0xc000199200) at gopkg.in/natefinch/lumberjack.v2@v2.0.0/lumberjack.go:381
#8 0x000055f9776d90c1 in runtime.goexit () at runtime/asm_amd64.s:1374
#9 0x000000c000199200 in ?? ()
#10 0x0000000000000000 in ?? ()
I think this is caused by @privileged set being deny-listed in the service file, chown(2) is one of the system call listed in capabilities(7) so deny-listing @privileged removes @chown set from the allow-list. I tested removing @privileged from the service file deny-list and the process is no longer killed by the kernel.