Bug#995793: exim4-base: /tmp partition has noexec mount option; exim4-base fails
Package: exim4-base Version: 4.94.2-7 Severity: grave Justification: renders package unusable X-Debbugs-Cc: s.egb...@sbcglobal.net Dear Maintainer, Tried to installed 'exim4-base' after its most recent update and failed. Implemented a rough draft of CIS Security Debian 11. The portion about /tmp mount partition having that 'noexec' mount option. Well, we will not be able to install exim4-base package anymore if this hardening effort continues. Besides, who is still trying execute a script in /tmp directory. Correct action is to do 'bash /tmp/your-script' or 'perl /tmp/your-script'. Not to execute directly from '/tmp/your-script'. Best action is not to execute that script directly in /tmp. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.46 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled -- no debconf information
Bug#995260: chrony: Mismatched filename for UNIX socket between client and daemon
Package: chrony
Version: 4.0-8
Severity: grave
Tags: upstream
Justification: renders package unusable
X-Debbugs-Cc: s.egb...@sbcglobal.net
Dear Maintainer,
The filename construct for a UNIX socket to be shared
between the Chrony (chronyd) daemon and its Chrony CLI (chronyc) client
admin tool are not in sync, as client's UNIX filename uses a PID value
whereas server's UNIX filename does not use PID value.
This appears to be a Debian-only issue.
Fired up its daemon and doubled checked that a UNIX socket was made:
$ ls -1 /run/chrony
chrony.sock
chrony.pid
Execute the client and no successful UNIX socket opened.
Using List Open File (lsof) tool, I show the daemon's opened files:
COMMAND PID USER FD TYPE NODE NAME
chronyd 3597 _chrony3u unix 0x \
type=DGRAM
chronyd 3597 _chrony5u IPv4 UDP 127.0.0.1:323
chronyd 3597 _chrony6u IPv6 UDP [::1]:323
chronyd 3597 _chrony7u unix 0x \
/run/chrony/chronyd.sock type=DGRAM
chronyd 3597 _chrony8u unix 0x type=SEQPACKET
chronyc 3809johnd3u IPv4 UDP \
127.0.0.1:33911->127.0.0.1:323
No socket in the dispatcher part of the daemon, now to check the other
forked part of the daemon used to carry on the connection with
its chronyc client, same 'lsof' output.
COMMAND PID USER FD TYPE NODE NAME
chronyd 3597 _chrony5u IPv4 UDP 127.0.0.1:323
chronyd 3597 _chrony6u IPv6 UDP [::1]:323
chronyd 3598 _chrony9u unix 0x type=SEQPACKET
chronyc 3809johnd3u IPv4 UDP \
127.0.0.1:33911->127.0.0.1:323
Appears that client failed socket open and fell back to a
different approach which is using an IP loopback address.
Investigated why socket open failed... by using 'strace -f chrony[c|d]'.
For the chronyd v4.0 having opened a Debian-tweaked '/run/chrony/chrony.sock',
I show the corresponding chronyc v4.0 version:
$ chronyc -v
chronyc (chrony) version 4.0 (+READLINE +SECHASH +IPV6 -DEBUG)
And ran strace against this v4.0 client and grep'd for 'sock' word pattern:
$ strace -f /usr/bin/chronyc
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/run/chrony/chronyc.3875.sock") = -1 EACCES (Permission denied)
bind(3, {sa_family=AF_UNIX, sun_path="/run/chrony/chronyc.3875.sock"}, 110)
= -1 EACCES (Permission denied)
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
close(3)= 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(323),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
Noticed the 'PID' number being inserted into the
'/run/chrony/chronyc.3875.sock'?
This is the chronyc client doing "PID-sock" filenaming convention, whereas
its daemon is doing a different "just-sock" filenaming convention.
The v4.1 client does exactly the same.
chronyc (chrony) version DEVELOPMENT (-READLINE -SECHASH +IPV6 +DEBUG)
socket(AF_UNIX, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, 0) = 3
unlink("/var/run/chrony/chronyc.3885.sock") = -1 EACCES (Permission denied)
bind(3, {sa_family=AF_UNIX, sun_path="/var/run/chrony/chronyc.3885.sock"},
110) = -1 EACCES (Permission denied)
getsockname(3, {sa_family=AF_UNIX}, [112->2]) = 0
close(3)= 0
socket(AF_INET, SOCK_DGRAM|SOCK_CLOEXEC|SOCK_NONBLOCK, IPPROTO_IP) = 3
connect(3, {sa_family=AF_INET, sin_port=htons(323),
sin_addr=inet_addr("127.0.0.1")}, 16) = 0
fstat(0, {st_mode=S_IFCHR|0620, st_rdev=makedev(0x88, 0), ...}) = 0
read(0, ^Cstrace: Process 3885 detached
It would be nice to use consistent filenaming convention for the UNIX socket
for both client and daemon.
-- System Information:
Debian Release: 11.0
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 5.10.46 (SMP w/4 CPU threads)
Kernel taint flags: TAINT_UNSIGNED_MODULE
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages chrony depends on:
ii adduser 3.118
ii init-system-helpers 1.60
ii iproute2 5.10.0-4
ii libc62.31-13
ii libcap2 1:2.44-1
ii libedit2 3.1-20191231-2+b1
ii libgnutls30 3.7.1-5
ii libnettle8 3.7.3-1
ii libseccomp2 2.5.1-1
ii tzdata 2021a-1
ii ucf 3.0043
chrony recommends no packages.
Versions of packages chrony suggests:
ii bind9-dnsutils [dnsutils] 1:9.16.15-1
pn networkd-dispatcher
-- Config
Bug#995207: chrony: Using 'bindacqdevice' directive causes a SIGSYS error
Package: chrony Version: 4.0-8 Severity: critical Tags: upstream X-Debbugs-Cc: s.egb...@sbcglobal.net Dear Maintainer, Wanted to use the 'bindacqdevice' due to my host having a dynamic IP interface. Using that 'bindacqdevice' directive keyword anywhere in my /etc/chrony/chrony.conf file results in a signal 31 (according to Linux auditd). My guess is that attempts to do a Chrony as a NTP server (disbursing out NTP beacons), we need to have an socket open on this dynamic IP interface. This is the setting of the systemd resource. Removing the 'bindacqdevice' directive, and all works perfectly. Was half-expecting to be able to use 'bindacqdevice' configuration directive here. -- System Information: Debian Release: 11.0 APT prefers stable-updates APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10.46 (SMP w/4 CPU threads) Kernel taint flags: TAINT_UNSIGNED_MODULE Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) LSM: AppArmor: enabled Versions of packages chrony depends on: ii adduser 3.118 ii init-system-helpers 1.60 ii iproute2 5.10.0-4 ii libc62.31-13 ii libcap2 1:2.44-1 ii libedit2 3.1-20191231-2+b1 ii libgnutls30 3.7.1-5 ii libnettle8 3.7.3-1 ii libseccomp2 2.5.1-1 ii tzdata 2021a-1 ii ucf 3.0043 chrony recommends no packages. Versions of packages chrony suggests: ii bind9-dnsutils [dnsutils] 1:9.16.15-1 pn networkd-dispatcher -- Configuration Files: /etc/default/chrony changed: DAEMON_OPTS="-F 1 -L 0" -- no debconf information
Bug#822075: apt-file: Fails to install apt-file-2.5.4 due to requiring older perl-base-5.20
Package: apt-file Version: 2.5.4 Severity: grave Tags: d-i Justification: renders package unusable Dear Maintainer, Attempted to install apt-file package and got an error On 2016/04/20, did a apt-get update/upgrade to ensure current up-to-date. * What exactly did you do (or not do) that was effective (or ineffective)? Executed the following command: apt-get install apt-file * What was the outcome of this action? Package did not install. Output is: sudo apt-get install apt-file Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: apt-file : Depends: libapt-pkg-perl but it is not going to be installed Depends: liblist-moreutils-perl but it is not going to be installed E: Unable to correct problems, you have held broken packages. steve@arca:~/work/shockwave/jsunpack-n/depends/js-1.8.0-rc1-src/Linux_All_DBG.OBJ$ sudo apt-get install libapt-pkg-perl Reading package lists... Done Building dependency tree Reading state information... Done Some packages could not be installed. This may mean that you have requested an impossible situation or if you are using the unstable distribution that some required packages have not yet been created or been moved out of Incoming. The following information may help to resolve the situation: The following packages have unmet dependencies: libapt-pkg-perl : Depends: perlapi-5.20.0 E: Unable to correct problems, you have held broken packages. * What outcome did you expect instead? apt-fail package to install successfully. -- System Information: Debian Release: stretch/sid APT prefers stable APT policy: (990, 'stable'), (500, 'stable-updates') Architecture: amd64 (x86_64) Kernel: Linux 4.0.0-2-amd64 (SMP w/2 CPU cores) Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system)
