openSUSE Bugs September 2021

bugs@lists.opensuse.org

1 participants
2745 discussions

[Bug 1184457] New: Additional, non-specified, firewall rules are being added during the deployment

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1184457 Bug ID: 1184457 Summary: Additional, non-specified, firewall rules are being added during the deployment Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: x86-64 OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: AutoYaST Assignee: yast2-maintainers(a)suse.de Reporter: mail(a)georg-pfuetzenreuter.net QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 848067 --> http://bugzilla.opensuse.org/attachment.cgi?id=848067&action=edit save_y2logs Hello, after installing a system using an AutoYaST profile, additional, opened, Firewall services are added, in addition to the specified Firewall rules. The autoinst.xml being used: http://deploy.squirrelcube.xyz/autoinst_latest.xml ylogs: Attached. The firewall rules observed to having been added in addition to my specified ones: Zones -> DMZ -> Allowed: ssh Zones -> External -> Allowed: ssh Zones -> home -> Allowed: dhcpv6-client, mdns, samba-client, ssh Zones -> internal -> Allowed: dhcpv6-client, mdns, samba-client, ssh Zones -> public -> Allowed: dhcpv6-client Zones -> work -> Allowed: dhcpv6-client, ssh Best, Georg -- You are receiving this mail because: You are on the CC list for the bug.

1 hour, 22 minutes

[Bug 1184804] New: move kernel out of /boot

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1184804 Bug ID: 1184804 Summary: move kernel out of /boot Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- One of the motivations for UsrMerge is to have all read-only parts of the operating system in /usr. The kernel packages install files in /boot though which isn't in line with that idea. Having the kernel installed via rpm in /boot also causes issues with eg snapshots if /boot is on a separate partition. So it make sense to store the rpm provided parts of the kernel packages where the rest of the OS is and manage /boot separately. Looking at Fedora they install files like vmlinuz that used to be named /boot/$name-$kver as (/usr)/lib/modules/$kver/$name instead. They include /boot/$name-$kver as %ghost. -- You are receiving this mail because: You are on the CC list for the bug.

18 hours, 54 minutes

[Bug 1189024] New: Sway: potential name conflict pattern vs package

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1189024 Bug ID: 1189024 Summary: Sway: potential name conflict pattern vs package Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: All OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Patterns Assignee: dimstar(a)opensuse.org Reporter: tammo.oepkes(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 851501 --> http://bugzilla.opensuse.org/attachment.cgi?id=851501&action=edit Screenshot from sway install on minimal system There are a package and a pattern which are both called `sway`. If one attempts to install the sway package, the pattern unintentionally gets installed. Reproduce: - install Tumbleweed, choose server install (to get minimal system) - modify `/etc/zypp/zypp.conf`: `solver.onlyRequires = true` - modify `/etc/zypp/zypper.conf`: `installRecommends = no` - run dist-upgrade - run `zypper install sway` This will attempt to install the sway _pattern_ (with 196 packages, consuming 343 MiB). For comparison, an i3 installation attempt on the same (minimal) system attempts to install 23 packages, weighing only 6.9 MiB. I tried to install sway package (instead of pattern) explicitly with `zypper install --type package sway`, but this yields the same result as omitting the switch. My assumption is that the identical names for pattern and package cause unintended behavior. -- You are receiving this mail because: You are on the CC list for the bug.

22 hours, 30 minutes

[Bug 1176052] New: btrfsmainenance doesn't work with read-only root fs

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1176052 Bug ID: 1176052 Summary: btrfsmainenance doesn't work with read-only root fs Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kubic Assignee: kubic-bugs(a)opensuse.org Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- btrfsmaintenance uses "/" as default filesystem, but the btrfs commands will not work with it since this is read-only on transactional-server and MicroOS. Use /.snapshots instead, as it is on the same filesystem but writeable. -- You are receiving this mail because: You are on the CC list for the bug.

23 hours, 33 minutes

[Bug 1161264] New: ignition, /root and installing ssh key

by bugzilla_noreply＠novell.com

http://bugzilla.suse.com/show_bug.cgi?id=1161264 Bug ID: 1161264 Summary: ignition, /root and installing ssh key Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: iforster(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de CC: fvogt(a)suse.com Found By: --- Blocker: --- We have a chicken/egg problem with ignition and installing a root ssh key on a transactional-update system: /root is not mounted in initrd, you need to add an entry in the ignition config to mount /root. To do that, you need to know the device name. Which leads to two problems: 1. I don't know the device name upfront, I need to login first. But's that's not possible without working ignition config. 2. The device name varies on different machines. So you need an extra config/usb disk for every different machine. -- You are receiving this mail because: You are on the CC list for the bug.

23 hours, 34 minutes

[Bug 1156421] New: devel:kubic:images: no persistent systemd journal for aarch64/armv7l

by bugzilla_noreply＠novell.com

http://bugzilla.suse.com/show_bug.cgi?id=1156421 Bug ID: 1156421 Summary: devel:kubic:images: no persistent systemd journal for aarch64/armv7l Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: fvogt(a)suse.com Reporter: kukuk(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The images for Raspberry Pi 2/3 from devel:kubic:images have no persistent systemd journal logging, the x86-64 has. The /var/log/journal directory seems to exist, no idea why the log is written to /run/log/journal instead. -- You are receiving this mail because: You are on the CC list for the bug.

23 hours, 34 minutes

[Bug 1186677] New: Leap 15.3 gold master - Ethernet controller added as wlan0

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1186677 Bug ID: 1186677 Summary: Leap 15.3 gold master - Ethernet controller added as wlan0 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: aarch64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: axel.braun(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I booted a Raspi4 from USB stick for installation of Leap 15.3 build 160 (gold master), and there was no network autodetected (ethernet cable plugged in!) On the Network settings page it offers ARM Ethernet controller as wlan0, and showing all WIFI options, but it does not find any wireless network. I could add manually an ethernet device eth0, which then enables to add online-repositories. See: https://lists.opensuse.org/archives/list/arm@lists.opensuse.org/thread/7JHA… -- You are receiving this mail because: You are on the CC list for the bug.

1 day, 22 hours

[Bug 1173619] New: VUL-0: unbound: LPE from unbound to root

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1173619 Bug ID: 1173619 Summary: VUL-0: unbound: LPE from unbound to root Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: darin(a)darins.net Reporter: wolfgang.frisch(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- via security(a)suse.de: I believe to have found a configuration issue in the Unbound package. Or, depending on how you look at it, in the Unbound server itself. 1. Before starting the Unbound server, systemd routinely runs unbound-anchor. From 'systemctl cat unbound': ExecStartPre=/usr/bin/sudo -u unbound /usr/sbin/unbound-anchor -a /var/lib/unbound/root.key -c /etc/unbound/icannbundle.pem As you can see this process is run as user unbound. 2. The Unbound server writes a pid file before dropping privileges, i.e. as root. It then chown's the file in a second step. 'grep username /etc/unbound/unbound.conf': username: "unbound" And from the Unbound source: https://github.com/NLnetLabs/unbound/blob/2a90e8fa1e22aa75d1cf67a1f71ebbf3f… As you can see in the source, Unbound doesn't check if there is already a symbolic link in place of the pid file. 3. openSUSE configures Unbound to create the pid file in a directory owned by the unbound user. 'grep pidfile /etc/unbound/unbound.conf': pidfile: "/var/run/unbound/unbound.pid" 'cat /usr/lib/tmpfiles.d/unbound.conf': D /run/unbound 0755 unbound unbound - 4. unbound-anchor is a nice little "do-one-thing-and-do-it-right" tool. But if it is compromised, and as it has write permission in the pid file directory and reliably runs before the server, an attacker could easily gain full root privileges by just creating a symbolic link /run/unbound/unbound.pid. 5. IMHO this would be best fixed in openSUSE by creating a root owned /run/unbound directory, or changing the pid file path to /run/unbound.pid or something like that. I think this would have the added advantage that openSUSE could ship and maybe enforce the Unbound AppArmor profile used in Debian and Ubuntu: https://gitlab.com/apparmor/apparmor-profiles/-/blob/master/ubuntu/20.04/us… With the current openSUSE setup there is the problem that if AppArmor filters CAP_DAC_OVERRIDE, Unbound has no permission to create a pid file in /run/unbound anymore. If you have questions please don't hesitate to contact me. Thanks for taking a look. Kind regards, Detlef -- You are receiving this mail because: You are on the CC list for the bug.

2 days, 1 hour

[Bug 1116084] New: Auto-mounting encrypted external disk requires root password

by bugzilla_noreply＠novell.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1116084 Bug ID: 1116084 Summary: Auto-mounting encrypted external disk requires root password Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: bnc-team-screening(a)forge.provo.novell.com Reporter: opensuserg(a)thefifthcontinent.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Operating System: openSUSE Tumbleweed 20181110 KDE Plasma Version: 5.14.3 Qt Version: 5.11.2 KDE Frameworks Version: 5.51.0 Kernel Version: 4.18.15-1-default OS Type: 64-bit Processors: 4 × Intel® Core™ i7-7500U CPU @ 2.70GHz Memory: 7.7 GiB of RAM When auto-mounting an encrypted USB drive, it asks for the encryption password and if that is correct, it asks for the root password to perform the mount. When manually mounting the same drives, the root password is not required. This is the expected behaviour. -- You are receiving this mail because: You are on the CC list for the bug.

2 days, 18 hours

[Bug 1181533] New: Is not possible to set date with UTC format and 2038 year using hwclock

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1181533 Bug ID: 1181533 Summary: Is not possible to set date with UTC format and 2038 year using hwclock Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: ionut_n2001(a)yahoo.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Hi SUSE Team, I try to set date with UTC format and 2038 Year. This is not working. Steps for reproduce: # date -s "Jan 20 15:42:59 UTC 2038" # hwclock -w # hwclock -s hwclock: settimeofday() failed: Invalid argument -- You are receiving this mail because: You are on the CC list for the bug.

2 days, 20 hours

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs September 2021