April 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1160604] New: BTRFS related kernel NULL pointer dereference
by bugzilla_noreply＠novell.com 03 Dec '21

03 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1160604 Bug ID: 1160604 Summary: BTRFS related kernel NULL pointer dereference Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-maintainers(a)forge.provo.novell.com Reporter: guillaume.gardet(a)arm.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 827267 --> http://bugzilla.opensuse.org/attachment.cgi?id=827267&action=edit kernel 5.4 traces On OBS while building JeOS images based on BTRFS filesystem, kernel crashes with a kernel NULL pointer dereference. There was no problem kernel 5.3, only with 5.4. Traces are in attachment. -- You are receiving this mail because: You are on the CC list for the bug.

2 26

[Bug 1163588] New: AUDIT-FIND: chromium: chrome_sandbox shouldn't be packaged any more
by bugzilla_noreply＠novell.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1163588 Bug ID: 1163588 Summary: AUDIT-FIND: chromium: chrome_sandbox shouldn't be packaged any more Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: tchvatal(a)suse.com Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: security-team(a)suse.de Found By: --- Blocker: --- I just noticed that on openSUSE we're shipping the chromium browser still with the setuid-root sandbox in /usr/lib/chrome_sandbox. This should NOT be necessary any more, since chromium uses Linux namespaces these days for sandboxing. The chome_sandbox binary should not need to be built and shipped at all. Upstream worked for years on making this possible: https://bugs.chromium.org/p/chromium/issues/detail?id=312380 By now it is possible for a longer time already to run without this setuid-root binary. Since openSUSE kernels should all support namespaces there should be no compelling reason to keep this setuid program around. Please adjust the packaging accordingly. Afterwards the security team can remove the entry from the permissions package. Thank you. -- You are receiving this mail because: You are on the CC list for the bug.

2 13

[Bug 1150366] New: AUDIT-1: ceph-common: review of setgid directory /var/log/ceph
by bugzilla_noreply＠novell.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1150366 Bug ID: 1150366 Summary: AUDIT-1: ceph-common: review of setgid directory /var/log/ceph Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jsegitz(a)suse.com, malte.kraus(a)suse.com, matthias.gerstner(a)suse.com, ncutler(a)suse.com Blocks: 1150189 Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1150189 Like discussed in the proactive security team we want to catch up with packages installing set*id items that haven't been whitelisted yet in the permissions package. Formerly this rpmlint check type didn't cause badness and therefore didn't require packagers to actually have them reviewed. ceph-common is one of the packages installing a setgid directory that isn't currently whitelisted: /var/log/ceph drwxrws--T from ceph-common-14.2.2.354+g8878cf2360-1.1.x86_64.rpm The secure use of this directory needs to be reviewed and if all is good a whitelisting entry in all our permission profiles must be added. -- You are receiving this mail because: You are on the CC list for the bug.

2 9

[Bug 1150345] New: AUDIT-1: nagios: review of setgid directory /var/spool/nagios
by bugzilla_noreply＠novell.com 02 Dec '21

02 Dec '21

http://bugzilla.suse.com/show_bug.cgi?id=1150345 Bug ID: 1150345 Summary: AUDIT-1: nagios: review of setgid directory /var/spool/nagios Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: matthias.gerstner(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jsegitz(a)suse.com, malte.kraus(a)suse.com, matthias.gerstner(a)suse.com Found By: --- Blocker: --- +++ This bug was initially created as a clone of Bug #1150189 Like discussed in the proactive security team we want to catch up with packages installing set*id items that haven't been whitelisted yet in the permissions package. Formerly this rpmlint check type didn't cause badness and therefore didn't require packagers to actually have them reviewed. Nagios is one of the packages installing a setgid directory that isn't currently whitelisted: /var/spool/nagios drwxrwsr-x from nagios-4.4.3-3.1.i586.rpm The secure use of this directory needs to be reviewed and if all is good a whitelisting entry in all our permission profiles must be added. -- You are receiving this mail because: You are on the CC list for the bug.

2 5

[Bug 1140772] New: openconnect: please update vpnc-script
by bugzilla_noreply＠novell.com 02 Dec '21

02 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1140772 Bug ID: 1140772 Summary: openconnect: please update vpnc-script Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: gernot(a)hillier.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Current openconnect package from openSUSE:factory still includes a vpnc-script dating back at least 2 years (file date according to OBS: 2017-09-22, see https://build.opensuse.org/package/show/network/openconnect) Please update this file to a current version from the vpnc-script repository of David Woodhouse (openconnect author), see http://git.infradead.org/users/dwmw2/vpnc-scripts.git/blob/refs/heads/maste…. This brings a lot of improvements for non-trivial network setups, IPv6 etc., see http://git.infradead.org/users/dwmw2/vpnc-scripts.git/shortlog - including necessary extensions we need for using OpenConnect at Siemens. :) Thanks! -- You are receiving this mail because: You are on the CC list for the bug.

2 3

[Bug 972787] New: [gpg-agent] Rework agent startup for DM sessions.
by bugzilla_noreply＠novell.com 01 Dec '21

01 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=972787 Bug ID: 972787 Summary: [gpg-agent] Rework agent startup for DM sessions. Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE 42.1 Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: eich(a)suse.com QA Contact: qa-bugs(a)suse.de CC: astieger(a)suse.com, meissner(a)suse.com, premysl.janouch(a)suse.com, werner(a)suse.com, xorg-maintainer-bugs(a)forge.provo.novell.com Found By: Development Blocker: --- The gpg-agent for a user session is started by the script /etc/X11/xdm/sys.xsession. An openSUSE user pointed out to me that the socket handling of the gpg-agent has changed with gpg 2.1 - now neither a env file is written (the option --write-env-file is ignored) nor nor does anything use the env variable GPG_AGENT_INFO. Instead today a standard socket is used in $HOME/.gnupg/S.gpg-agent. Also check: https://gnupg.org/faq/whats-new-in-2.1.html If NFS mounted homes are desired, it can be handled as described in: https://wiki.gnupg.org/NFS This requires reworking of the gpg-agent startup (and possibly also of the ssh-agent) in sys.xsession. Any takers? -- You are receiving this mail because: You are on the CC list for the bug.

2 4

[Bug 1099755] New: /etc/hosts.allow /etc/hosts.deny not support ssh
by bugzilla_noreply＠novell.com 01 Dec '21

01 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1099755 Bug ID: 1099755 Summary: /etc/hosts.allow /etc/hosts.deny not support ssh Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Factory Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: simon(a)becherer.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- wrong security feeling, because text of file /etc/hosts.allow is wrong. written is: # /etc/hosts.allow # See 'man tcpd' and 'man 5 hosts_access' for a detailed description # of /etc/hosts.allow and /etc/hosts.deny. # # short overview about daemons and servers that are built with # tcp_wrappers support: #. # package name | daemon path | token # ---------------------------------------------------------------------------- # ssh, openssh | /usr/sbin/sshd | sshd, sshd-fwd-x11, sshd-fwd-<port> # quota | /usr/sbin/rpc.rquotad | rquotad # tftpd | /usr/sbin/in.tftpd | in.tftpd # portmap | /sbin/portmap | portmap at least toke sshd to allow and deny will not work any more on actual systems (tumbleweed). (maybe others tokens also affected) so user (as i) with low background knowlidge will feel secure if they make settings like: sshd : ALL : deny sshd : 127.0.0.1 : allow sshd : 192.168.0.30 : allow but the system ignores this. -> leading text and maybe manpage has to be changed! -> or if this 2 files host.allow / hosts.deny ar complete obsolete, do not install it at all. -- You are receiving this mail because: You are on the CC list for the bug.

2 1

[Bug 1154134] New: Remote desktop access using xrdp/xfreerdp crashes when the clipboard is used
by bugzilla_noreply＠novell.com 01 Dec '21

01 Dec '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1154134 Bug ID: 1154134 Summary: Remote desktop access using xrdp/xfreerdp crashes when the clipboard is used Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: suChenshaw(a)talisiorder.ca QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When connecting two computers, both running Leap, via RDP using xrdp/xorgxrdp (server) and freerdp (client), the remote connection will terminate if anything is copied to the clipboard inside the RDP session. Steps to replicate: 1. Install Leap on two separate computers, or VMs, joined with network connectivity. In my environment I have the minimal graphical install (Icewm) on the server and KDE on the client. I do not know if changing the server desktop environment would have any impact. 2. Install and configure xrdp and xorgxrdp on the server. 3. Install xfreerdp on the client. 4. From the client, connect to the server by executing: xfreerdp /v:<ip address> /u:<username> /size:1600x900 /bpp:32 /relax-order-checks +glyph-cache The parameters /relax-order-checks and +glyph-cache are necessary to work around known incompatibilities between xrdp and xfreerdp. 5. Working with the server through the RDP session, copy any text into the clipboard. I have copied text using xterm, Sakura and gedit, all with equal results. 6. The RDP session will terminate. On the client, xfreerdp will show the following errors: [20:02:38:767] [58978:58984] [ERROR][com.freerdp.channels.cliprdr.client] - Invalid short format list length: 24 [20:02:38:767] [58978:58984] [ERROR][com.freerdp.channels.cliprdr.client] - cliprdr_process_format_list failed with error 1359! [20:02:38:767] [58978:58984] [ERROR][com.freerdp.channels.cliprdr.client] - cliprdr_order_recv failed with error 1359! [20:02:38:767] [58978:58979] [ERROR][com.freerdp.core] - cliprdr_virtual_channel_client_thread reported an error. Error was 1359 [20:02:38:767] [58978:58979] [ERROR][com.freerdp.core] - checkChannelErrorEvent() failed - 0 [20:02:38:767] [58978:58979] [INFO][com.freerdp.client.common] - Network disconnect! [20:02:38:767] [58978:58979] [ERROR][com.freerdp.client.x11] - Failed to check FreeRDP file descriptor Observations: Clipboard access when connecting to the (Leap) xrdp server using a Windows client running MSTSC works correctly. Clipboard access when connecting to a xrdp server running Kubuntu 18.04 LTS works correctly with Leap's xfreerdp. It's unclear if this is a bug in xrdp or xfreerdp. Workaround: Disable clipboard sharing. -- You are receiving this mail because: You are on the CC list for the bug.

2 2

[Bug 1146440] New: iputils-s20190709: arping -D is broken
by bugzilla_noreply＠novell.com 30 Nov '21

30 Nov '21

http://bugzilla.suse.com/show_bug.cgi?id=1146440 Bug ID: 1146440 Summary: iputils-s20190709: arping -D is broken Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: martin.wilck(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Duplicate address detection mode (DAD) is broken in arping. In DAD mode, if no responses are received, it should return 0. But: apollon:~ # arping -D -c 2 192.168.1.19; echo RESULT=$? ARPING 192.168.1.19 from 0.0.0.0 obr0 Sent 2 probes (2 broadcast(s)) Received 0 response(s) RESULT=1 This may break DHCP client scripts. -- You are receiving this mail because: You are on the CC list for the bug.

2 7

[Bug 1087860] New: wine repeatedly asks to install wine-mono even though the package wine-mono was installed
by bugzilla_noreply＠novell.com 29 Nov '21

29 Nov '21

http://bugzilla.opensuse.org/show_bug.cgi?id=1087860 Bug ID: 1087860 Summary: wine repeatedly asks to install wine-mono even though the package wine-mono was installed Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: Other URL: http://lord.arch/tests/737/modules/wine/steps/26 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: meissner(a)suse.com Reporter: okurz(a)suse.com QA Contact: okurz(a)suse.com Found By: --- Blocker: --- ## Observation After installing packages "wine" and "wine-mono" explicitly on openSUSE Leap build 184.1 and calling wine on even a trivial Windows program a dialog pops up to download and install a "wine-mono" package which should be there already. This can now also be reproduced in an openQA test: scenario opensuse-15.0-DVD-x86_64-wine@64bit in [wine](http://lord.arch.suse.de/tests/737/modules/wine/steps/26) ## Reproducible Every time on a clean installation of wine on openSUSE Leap 15.0 and I think just the same on openSUSE Tumbleweed. Might also be on openSUSE Leap 42.3 but I am not sure about this. ## Expected result There should be no question for wine-mono installation if the system package is alread installed OR a better description of the system package describing what it is actually used for. I think the problem is that even if someone would answer "yes" to the question to install the internal (non-openSUSE) wine-mono package the next time the question pops up again but I'm not 100% sure on this. ## Further details Always latest result in this scenario: [latest](http://lord.arch/tests/latest?arch=x86_64&test=wine&machine=64bit&flavor=DVD&version=15.0&distri=opensuse) -- You are receiving this mail because: You are on the CC list for the bug.

2 3