openSUSE Bugs February 2022

bugs@lists.opensuse.org

1 participants
3418 discussions

[Bug 1194945] New: Cifs `umount` returns 32 and `df` fails with no permission

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1194945 Bug ID: 1194945 Summary: Cifs `umount` returns 32 and `df` fails with no permission Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: openSUSE Leap 15.2 Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: mantel(a)pre-sense.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 855424 --> https://bugzilla.suse.com/attachment.cgi?id=855424&action=edit cifs kernel debug output Hello! We have encountered two CIFS-issues which appear reproducible. But the conditions to reproduce are unknown to us. The setup is the following: - An linux client which mounts a cifs share. - Windows Server which offers the cifs share. Sadly, we could not determine which windows server versions are related in the bugs. - The cifs share contains subfolders for various users, which are readable for the users. - The parent folder is readable, but not writable for the users. - Example: //domain_name/company_users/username - company_users is a directory. the user has readonly permissions on that directory. - username is a subdirectory of company_users. the user has write permissions on that directory. We encounter two CIFS-issues. They might be considered as two seperate bugs, but since they occur in the same setup I just list them here: - `df` fails with permission denied when using it on the share. - `umount` of a cifs share fails with status code 32. Before the update to openSUSE Leap 15.2 the umount operation worked. It seems to be a regression. We could determine the kernel version which introduced the `umount` regression: ok 5.3.18-lp152.63.1 ok 5.3.18-lp152.66.2 ok 5.3.18-lp152.69.1 --> last kernel which can umount FAIL 5.3.18-lp152.72.1 FAIL 5.14.15-lp153.2.1.g3416a5a In an upstream forum was a description for enhanced debug informations of the kernel. You can find enhanced debug output in an attached file, at the end of the file (lines 721 - 739). You can also find the `df` permission denied at line 422. We dont know this is an actual regression. Every kernel we tried from openSUSE Leap 15.2 didn't work. We would like to debug this more but we have no clue how to continue at this point. Any help is welcome. Thanks, Alex -- You are receiving this mail because: You are on the CC list for the bug.

7 hours, 20 minutes

[Bug 1186365] New: Empty screen on Live XFCE in QEMU with virgl

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1186365 Bug ID: 1186365 Summary: Empty screen on Live XFCE in QEMU with virgl Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Xfce Assignee: bnc-team-xfce(a)forge.provo.novell.com Reporter: arvidjaar(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- I observed this both with Leap 15.3 current image and with Tumbleweed. I boot manually using "${QEMU_BIN}" \ -nodefaults \ -machine q35,accel=kvm \ -cpu kvm64 \ -m 2G \ -device virtio-scsi-pci \ -drive file=$HOME/tmp/openSUSE-Leap-15.3-XFCE-Live-x86_64-Build9.78-Media.iso,if=none,id=cd0,format=raw -device scsi-cd,drive=cd0,id=cd0 \ -netdev user,id=uplink -device virtio-net-pci,netdev=uplink \ -name "Leap 15.3 Live XFCE" \ -monitor unix:path="$QEMU_MONITOR_SOCKET",server=on,wait=off \ -vga virtio -display gtk,gl=on,zoom-to-fit=off,show-cursor=on \ & It boots and leaves me with empty screen. Switching to tty1 and logging in I see full graphical session correctly started, all processes present, just no output on tty7. This works if I disable OpenGL (-display gtk,gl=off). The KDE Live image boots normally using the same command line. TW XFCE Live image has the same issue. Regular TW GNOME and KDE both work with virgl. Host - Ubuntu 20.04 with GNOME Wayland session. QEMU emulator version 6.0.0 (v6.0.0-1-gd11fb9fde1) virglrenderer-0.7.0-1138-g3639155 Both compiled from source. QEMU has single patch to fix mouse positioning in gtk under Wayland. -- You are receiving this mail because: You are on the CC list for the bug.

8 hours, 18 minutes

[Bug 1193984] New: SELinux: targeted: rpcinfo violation

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1193984 Bug ID: 1193984 Summary: SELinux: targeted: rpcinfo violation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: okir(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- This is with Leap 15.3 and the targeted SELinux policy from MicroOS 5.1 This is a two-node configuration. Running rpcinfo on the client, trying to perform a NULL call to the server's rpcbind: /sbin/rpcinfo -T udp $server_ip portmapper The test user is tied to SELinux user staff_u. This results in the following audit message: audit: type=1400 audit(1640160326.582:12): avc: denied { name_bind } for pid=4754 comm="rpcinfo" src=690 scontext=staff_u:staff_r:staff_t:s0-s0:c0.c1023 tcontext=system_u:object_r:hi_reserved_port_t:s0 tclass=udp_socket permissive=1 It's possible that this is harmless (rpcinfo may just try to do a bindresvport() call in case it's running with privileges). However, in order to avoid noise, we may want to patch this out for euid != 0. -- You are receiving this mail because: You are on the CC list for the bug.

8 hours, 52 minutes

[Bug 1195904] New: SELinux: targeted: ssh violation

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1195904 Bug ID: 1195904 Summary: SELinux: targeted: ssh violation Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: okir(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- The following happens with the SELinux packages from MicroOS 5.1 on SLES15SP3. User "testuser" has been assigned SELinux user user_u and attempts to log in via ssh, using key authentication TEST: verify that the SSH key we generated can be used for authentication == Authorizing ssh key id_rsa == client: echo $HOME; user=testuser client: downloading /home/testuser/.ssh/id_rsa.pub server: mkdir -m 0755 -p ~/.ssh; user=testuser server: uploading data to /home/testuser/.ssh/authorized_keys client: ssh -oStrictHostKeyChecking=no server true; user=testuser Warning: Permanently added 'server,192.168.121.205' (ECDSA) to the list of known hosts. Failing: server: SELinux policy violation server: by systemd (pid=4281; context=user_u:user_r:user_t:s0; permissive=1) server: create access to dir inaccessible (dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0) server: create access to file reg (dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0) server: create access to fifo_file fifo (dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0) server: create access to sock_file sock (dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0) server: create access to lnk_file .#invocation:dbus.socketbf6abda56b666fe5 (dev=None; ino=None; context=system_u:object_r:user_tmp_t:s0) OK, RSA key authentication seems to work FAIL: server: SELinux policy violation -- You are receiving this mail because: You are on the CC list for the bug.

11 hours, 1 minute

[Bug 1189907] New: gnome-software: packages from the main distro repository should not be marked as potentially dangerous

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1189907 Bug ID: 1189907 Summary: gnome-software: packages from the main distro repository should not be marked as potentially dangerous Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: GNOME Assignee: gnome-bugs(a)suse.de Reporter: mrueckert(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- it should work more like software.o.o categorizes packages. i think the main culprit might be that it doesnt have any permissions information like it has for flatpak based apps. -- You are receiving this mail because: You are on the CC list for the bug.

11 hours, 20 minutes

[Bug 1172650] New: MicroOS: License not displayed in german

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1172650 Bug ID: 1172650 Summary: MicroOS: License not displayed in german Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: axel.braun(a)gmx.de QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 838577 --> http://bugzilla.opensuse.org/attachment.cgi?id=838577&action=edit empty license screen When installing MicroOS (snapshot:20200604) in german, the installation page 'Language, Keyboard and license contains am empty license -- You are receiving this mail because: You are on the CC list for the bug.

11 hours, 20 minutes

[Bug 1194705] New: [SELinux] Problems with colord

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1194705 Bug ID: 1194705 Summary: [SELinux] Problems with colord 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: mcepl(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- See what I��ve found in the journal: Jan 14 17:11:08 stitny colord[19334]: CdMain: failed to load mapping database: Can't open database: unable to open database file Jan 14 17:11:08 stitny systemd[1]: colord.service: Main process exited, code=exited, status=1/FAILURE Jan 14 17:11:08 stitny systemd[1]: colord.service: Failed with result 'exit-code'. Jan 14 17:11:08 stitny systemd[1]: Failed to start Manage, Install and Generate Color Profiles. Jan 14 17:11:08 stitny kernel: audit: type=1400 audit(1642176668.663:44015): avc: denied { read write } for pid=19334 comm="colord" name="mapping.db" dev="nvme0n1p2" ino=14847 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:colord_var_lib_t:s0 tclass=file permissive=0 Jan 14 17:11:08 stitny kernel: audit: type=1400 audit(1642176668.663:44016): avc: denied { read } for pid=19334 comm="colord" name="mapping.db" dev="nvme0n1p2" ino=14847 scontext=system_u:system_r:init_t:s0 tcontext=system_u:object_r:colord_var_lib_t:s0 tclass=file permissive=0 Using colord-1.4.5-4.2.x86_64 and selinux-policy-20211111-1.2.noarch -- You are receiving this mail because: You are on the CC list for the bug.

13 hours, 49 minutes

[Bug 1190847] New: gparted shows suse-specific "type" flag

by bugzilla_noreply＠suse.com

https://bugzilla.suse.com/show_bug.cgi?id=1190847 Bug ID: 1190847 Summary: gparted shows suse-specific "type" flag Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: screening-team-bugs(a)suse.de Reporter: aschnell(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- gparted shows the suse-specific "type" flag for partitions of an MS-DOS label. Trying to unset the flag results in an error popup followed by a crash. The problem does not happen when installing upstream (lib)parted. So likely the "type" patch for our parted should be improved. The "type" flag also does not behave like the other flags. -- You are receiving this mail because: You are on the CC list for the bug.

17 hours, 9 minutes

[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.

1 day, 2 hours

[Bug 1196224] New: User Kerberos Tickets are not refresh or get destroyed after Update to samba 4.15.4

by bugzilla_noreply＠suse.com

http://bugzilla.opensuse.org/show_bug.cgi?id=1196224 Bug ID: 1196224 Summary: User Kerberos Tickets are not refresh or get destroyed after Update to samba 4.15.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.3 Hardware: x86-64 OS: openSUSE Leap 15.3 Status: NEW Severity: Critical Priority: P5 - None Component: Samba Assignee: samba-maintainers(a)SuSE.de Reporter: andreas.hauffe(a)tu-dresden.de QA Contact: samba-maintainers(a)SuSE.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Firefox/91.0 Build Identifier: At the end of January there was an update of Samba 4.13 to 4.15. Since this time all our clients, which are Windows-AD members, doesn't keep the user kerberos tickets like before. Either the tickets are not refreshed or the tickets are destroyed. This results in a crashed KDE Plasma in the morning when the users try to login again, since the clients/user accounts weren't able to write on the kerberized NFS-Home mounts after the tickets got lost. Reproducible: Always Steps to Reproduce: 1. Configure PAM-Winbind for User logins 2. Wait some hours and the user tickets are not in the ticket cache any more Actual Results: Crashed KDE Plasma due to unwriteable home mounts Expected Results: refreshed user tickets in the ticket cache smb.conf [global] netbios name = ilr114l security = ADS workgroup = ILRW realm = ILRW.ING.DOM.TU-DRESDEN.DE dedicated keytab file = /etc/krb5.keytab kerberos method = secrets and keytab template homedir = /home/home_ilrw/%U template shell = /bin/bash winbind refresh tickets = yes winbind separator = + idmap config * : backend = tdb idmap config * : range = 2000-2999 idmap config ILRW : backend = rid idmap config ILRW : range = 3000-9999 # UID aus RID fuer ILRW idmap config DOM : backend = rid idmap config DOM : range = 10000-9999999 # UID aus RID fuer DOM krb5.conf [libdefaults] default_realm = ILRW.ING.DOM.TU-DRESDEN.DE dns_lookup_realm = true dns_lookup_kdc = true ticket_lifetime = 24h renew_lifetime = 7d forwardable = true [realms] ILRW.ING.DOM.TU-DRESDEN.DE = { auth_to_local = RULE:[1:$0@$1](ILRW\.ING\.DOM\.TU-DRESDEN\.DE@.*)s/\.ING\.DOM\.TU-DRESDEN\.DE@/+/ auth_to_local = RULE:[1:$0@$1](DOM\.TU-DRESDEN\.DE@.*)s/\.TU-DRESDEN\.DE@/+/ auth_to_local = DEFAULT } -- You are receiving this mail because: You are on the CC list for the bug.

1 day, 5 hours

Jump to page:

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

openSUSE Bugs February 2022