Bug#870777: casync: Please migrate to openssl1.1 in Buster
Package: casync Version: 2-1 Severity: important Tags: sid buster User: pkg-openssl-de...@lists.alioth.debian.org Usertags: openssl-1.1-trans Please migrate to libssl-dev in the Buster cycle. Sebastian ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: forcibly merging 808887 870747
Processing commands for cont...@bugs.debian.org: > forcemerge 808887 870747 Bug #808887 [init-system-helpers] update-rc.d: bails out on stop-only services Bug #870747 [init-system-helpers] update-rc.d: enabling a default-disabled service fails: "foo Default-Start contains no runlevels, aborting." Removed indication that 870747 affects sks Marked as found in versions init-system-helpers/1.25. Bug #808887 [init-system-helpers] update-rc.d: bails out on stop-only services Marked as found in versions init-system-helpers/1.49. Added tag(s) patch. Merged 808887 870747 > thanks Stopping processing here. Please contact me if you need assistance. -- 808887: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=808887 870747: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870747 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed (with 1 error): forcibly merging 808887 070747
Processing commands for cont...@bugs.debian.org: > forcemerge 808887 070747 Bug #808887 [init-system-helpers] update-rc.d: bails out on stop-only services Failed to forcibly merge 808887: Unable to load bug 070747. > thanks Stopping processing here. Please contact me if you need assistance. -- Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: affects 870747
Processing commands for cont...@bugs.debian.org: > affects 870747 + sks Bug #870747 [init-system-helpers] update-rc.d: enabling a default-disabled service fails: "foo Default-Start contains no runlevels, aborting." Added indication that 870747 affects sks > thanks Stopping processing here. Please contact me if you need assistance. -- 870747: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870747 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870747: update-rc.d: enabling a default-disabled service fails: "foo Default-Start contains no runlevels, aborting."
Package: init-system-helpers
Version: 1.49
Severity: normal
Tags: patch
i have a system service that is disabled by default. the local
administrator is expected to do some not insignificant configuration
(often using tools shipped in the package) before the service can be
enabled.
This service prefers an empty Default-Start: line, and a full
Default-Stop: line. The administrator is expected to enable it with
"update-rc.d foo enable" when they're ready.
however, this fails with:
foo Default-Start contains no runlevels, aborting.
Even worse, if i set up a systemd .service file for the same service,
with a vendor preset (systemd.preset(5)) disabled to achieve the same
goal, then when the admin manually enables the service with "systemctl
enable foo" then /lib/systemd/systemd-sysv-install just directly
invokes "update-rc.d foo enable" with no extra arguments, which itself
causes systemctl itself to fail.
So fixing this misbehavior in update-rc.d should actually let
"systemctl enable" start working again.
--dkg
-- System Information:
Debian Release: buster/sid
APT prefers testing-debug
APT policy: (500, 'testing-debug'), (500, 'testing'), (500, 'oldstable'),
(200, 'unstable-debug'), (200, 'unstable'), (1, 'experimental-debug'), (1,
'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386
Kernel: Linux 4.11.0-1-amd64 (SMP w/4 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8),
LANGUAGE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages init-system-helpers depends on:
ii perl-base 5.26.0-4
init-system-helpers recommends no packages.
init-system-helpers suggests no packages.
Versions of packages init-system-helpers is related to:
ii insserv 1.14.0-5.4+b1
-- no debconf information
From 743df08123f386f8a04cad68121de83fc1d17c9d Mon Sep 17 00:00:00 2001
From: Daniel Kahn Gillmor
Date: Fri, 4 Aug 2017 13:34:42 -0400
Subject: [PATCH] Support enabling default-disabled services.
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit
Some services want to be shipped disabled by default (their
Default-Start is empty, and their Default-Stop is 0 1 2 3 4 5 6)
The systemd equivalent is a systemd service shipped with a vendor
preset "disabled" (see systemd.preset(5)).
In that case "update-rc.d foo defaults" should do the same as
"update-rc.d foo disable" (though https://bugs.debian.org/808887 notes
that "disable" fails in this case -- this patch fixes 808887 as well).
But "update-rc.d foo enable" for a service that is shipped disabled by
default ought to actually enable it. This is the administrator
deciding that they're ready to enable the initially-disabled service.
This already works for runlevel 3 if the admin says "update-rc.d foo
enable 3". But update-rc.d(8) says:
If no start runlevel is specified after the disable or enable
keywords, the script will attempt to modify links in all start
run‐ levels.
This patch assumes that the default runlevels (2, 3, 4, 5) are the
thing to enable if the administrator doesn't specify any runlevels
specifically, which matches widely held assumptions (e.g. in
/etc/init.d/skeleton). I don't think it would make sense to enable in
'S' without the admin explicitly asking for it.
---
script/update-rc.d | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/script/update-rc.d b/script/update-rc.d
index 6c8c0d0..c2a444c 100755
--- a/script/update-rc.d
+++ b/script/update-rc.d
@@ -393,7 +393,8 @@ sub sysv_toggle {
($start_lvls, $stop_lvls) = parse_def_start_stop($lsb_header);
@toggle_lvls = @$start_lvls;
if ($#toggle_lvls < 0) {
-error("$name Default-Start contains no runlevels, aborting.");
+warning("$name Default-Start contains no runlevels, using 2 3 4
5.");
+@toggle_lvls = qw(2 3 4 5);
}
}
--
2.13.2
___
Pkg-systemd-maintainers mailing list
Pkg-systemd-maintainers@lists.alioth.debian.org
http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870638: systemd: /var/log/btmp has inconsistent permissions
At the moment systemd sets the permissions/ownership on /var/log/btmp to 0600 root:utmp (in /usr/lib/tmpfiles.d/var.conf). If all the programs that need to read or write /var/log/btmp are already running with root privileges, then 0600 seems OK, and ownership might as well be root:root. This would require changes to /etc/logrotate.conf (in the logrotate package) and the post-installation script of the base-files package, otherwise the permissions on /var/log/btmp may change across reboots and logfile rotations. Mark. Michael Biebl writes: > Am 04.08.2017 um 11:27 schrieb Mark Charter: > > Michael, > > > > Thanks for your reply. > > > > /var/log/btmp should not be world readable because a common cause of > > login failures is to give password instead of username, which would > > result in passwords being world readable. See Debian bug 341883: > > > > Hm, if that is the case that passwords are logged to that file, do we > really want to make that file read/writable by group utmp? > > The Debian policy [1] only says that /var/log/wtmp,lastlog and > /var/run/utmp should be writable by group utmp. > > Given that, wouldn't it be a safer default to have 0600 root:root for > /var/log/btmp as systemd creates it? > > Michael > > [1] > https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.3 > > x[DELETED ATTACHMENT signature.asc, application/pgp-signature] ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870704: warn if native systemd service files only wrap existing SysV/LSB init scripts
Package: lintian Version: 2.5.52 Severity: normal Looking at https://codesearch.debian.net/search?q=Exec.*%3D%2Fetc%2Finit.d%2F there are quite a few native systemd .service file which simply use the existing SysV init script via ExecStart/ExecStop/... We should actively discourage that. For that I suggest to add a lintian check. Finding affected packages should be as simple as running grep "Exec.*=/etc/init.d/" on the .service files. The main logic of more complex init scripts should be moved into helper scripts which can be used directly from the service file and the init script. This will also make the init scripts more readable and easier to support other alternatives like runit or openrc. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages lintian depends on: ii binutils 2.29-3 ii bzip2 1.0.6-8.1 ii diffstat 1.61-1+b1 ii dpkg 1.18.24 ii file 1:5.30-1 ii gettext 0.19.8.1-2+b1 ii intltool-debian 0.35.0+20060710.4 ii libapt-pkg-perl 0.1.32+b2 ii libarchive-zip-perl 1.59-1 ii libclass-accessor-perl0.34-1 ii libclone-perl 0.38-2+b2 ii libdigest-sha-perl5.96-1+b3 ii libdpkg-perl 1.18.24 ii libemail-valid-perl 1.202-1 ii libfile-basedir-perl 0.07-1 ii libipc-run-perl 0.96-1 ii liblist-moreutils-perl0.416-1+b3 ii libparse-debianchangelog-perl 1.2.0-12 ii libperl5.26 [libdigest-sha-perl] 5.26.0-5 ii libtext-levenshtein-perl 0.13-1 ii libtimedate-perl 2.3000-2 ii liburi-perl 1.71-1 ii libxml-simple-perl2.24-1 ii libyaml-libyaml-perl 0.63-2+b2 ii man-db2.7.6.1-2 ii patchutils0.3.4-2 ii perl 5.26.0-5 ii t1utils 1.40-2 ii xz-utils 5.2.2-1.3 Versions of packages lintian recommends: ii libperlio-gzip-perl 0.19-1+b4 Versions of packages lintian suggests: pn binutils-multiarch ii dpkg-dev 1.18.24 ii libhtml-parser-perl3.72-3+b2 ii libtext-template-perl 1.46-1 -- no debconf information ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870638: systemd: /var/log/btmp has inconsistent permissions
Am 04.08.2017 um 11:27 schrieb Mark Charter: > Michael, > > Thanks for your reply. > > /var/log/btmp should not be world readable because a common cause of > login failures is to give password instead of username, which would > result in passwords being world readable. See Debian bug 341883: > Hm, if that is the case that passwords are logged to that file, do we really want to make that file read/writable by group utmp? The Debian policy [1] only says that /var/log/wtmp,lastlog and /var/run/utmp should be writable by group utmp. Given that, wouldn't it be a safer default to have 0600 root:root for /var/log/btmp as systemd creates it? Michael [1] https://www.debian.org/doc/debian-policy/ch-customized-programs.html#s11.3 signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870638: systemd: /var/log/btmp has inconsistent permissions
Michael, Thanks for your reply. /var/log/btmp should not be world readable because a common cause of login failures is to give password instead of username, which would result in passwords being world readable. See Debian bug 341883: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=341883 sshd (from OpenSSH) will refuse to write to /var/log/btmp if it is world readable. This comment is from openssh/loginrec.c: /* * Logs failed login attempts in _PATH_BTMP if that exists. * The most common login failure is to give password instead of username. * So the _PATH_BTMP file checked for the correct permission, so that * only root can read it. */ I don't think /var/log/wtmp or /var/run/utmp record failed logins, so they can be world readable. Mark. Michael Biebl writes: > Control: tags -1 + moreinfo > > Am 03.08.2017 um 18:46 schrieb Mark Charter: > > Package: systemd > > Version: 232-25+deb9u1 > > Severity: normal > > > > Dear Maintainer, > > > > When /var/log/btmp is created at installation (by > > /var/lib/dpkg/info/base-files.postinst) its permissions are 0660 > > (u=rw,g=rw,o=). When it is (re)created by log file rotation (in > > /etc/logrotate.conf) its permissions are also 0660. But if it is > > created by systemd, or after a reboot, its permissions (from > > /usr/lib/tmpfiles.d/var.conf) are 0600. So its permissions can change > > with time, and they often change across a reboot. > > > > I suggest that the three sources of file permissions should be made > > consistent, for example by changing the permissions in > > /usr/lib/tmpfiles.d/var.conf from > > > > f /var/log/btmp 0600 root utmp - > > > > to > > > > f /var/log/btmp 0660 root utmp - > > Why do /var/log/btmp and /var/log/utmp have different permissions, i.e. > 0660 vs 0664 in Debian? That seems inconsistent as well. > > > -- > Why is it that all of the instruments seeking intelligent life in the > universe are pointed away from Earth? > > x[DELETED ATTACHMENT signature.asc, application/pgp-signature] ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870697: Please provide systemd service file which doesn't require the SysV init script
Package: apparmor Version: 2.11.0-6+b2 Severity: normal Hi, currently apparmor.service is just a wrapper for the SysV init script: [Service] Type=oneshot RemainAfterExit=yes ExecStart=/etc/init.d/apparmor start ExecStop=/etc/init.d/apparmor stop ExecReload=/etc/init.d/apparmor reload Please provide a native service file which does not rely on the existence of the SysV init script. A reasonable approach could be to share common code in helper script that live in /lib/apparmor and can be called by both the init script and the service file. -- System Information: Debian Release: buster/sid APT prefers unstable APT policy: (500, 'unstable'), (200, 'experimental') Architecture: amd64 (x86_64) Foreign Architectures: i386 Kernel: Linux 4.11.0-2-amd64 (SMP w/4 CPU cores) Locale: LANG=de_DE.utf8, LC_CTYPE=de_DE.utf8 (charmap=UTF-8), LANGUAGE=de_DE.utf8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages apparmor depends on: ii debconf 1.5.63 ii init-system-helpers 1.49 ii libapparmor-perl 2.11.0-6+b2 ii libc62.24-14 ii lsb-base 9.20161125 ii python3 3.5.3-3 apparmor recommends no packages. Versions of packages apparmor suggests: ii apparmor-profiles2.11.0-6 pn apparmor-profiles-extra ii apparmor-utils 2.11.0-6+b2 -- debconf information excluded ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Processed: Re: Bug#870638: systemd: /var/log/btmp has inconsistent permissions
Processing control commands: > tags -1 + moreinfo Bug #870638 [systemd] systemd: /var/log/btmp has inconsistent permissions Added tag(s) moreinfo. -- 870638: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=870638 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
Bug#870638: systemd: /var/log/btmp has inconsistent permissions
Control: tags -1 + moreinfo Am 03.08.2017 um 18:46 schrieb Mark Charter: > Package: systemd > Version: 232-25+deb9u1 > Severity: normal > > Dear Maintainer, > > When /var/log/btmp is created at installation (by > /var/lib/dpkg/info/base-files.postinst) its permissions are 0660 > (u=rw,g=rw,o=). When it is (re)created by log file rotation (in > /etc/logrotate.conf) its permissions are also 0660. But if it is > created by systemd, or after a reboot, its permissions (from > /usr/lib/tmpfiles.d/var.conf) are 0600. So its permissions can change > with time, and they often change across a reboot. > > I suggest that the three sources of file permissions should be made > consistent, for example by changing the permissions in > /usr/lib/tmpfiles.d/var.conf from > > f /var/log/btmp 0600 root utmp - > > to > > f /var/log/btmp 0660 root utmp - Why do /var/log/btmp and /var/log/utmp have different permissions, i.e. 0660 vs 0664 in Debian? That seems inconsistent as well. -- Why is it that all of the instruments seeking intelligent life in the universe are pointed away from Earth? signature.asc Description: OpenPGP digital signature ___ Pkg-systemd-maintainers mailing list Pkg-systemd-maintainers@lists.alioth.debian.org http://lists.alioth.debian.org/cgi-bin/mailman/listinfo/pkg-systemd-maintainers
