April 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1210090] New: Kenrel 6.2.9 crash on boot when retbleed=stuff is enbaled
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210090 Bug ID: 1210090 Summary: Kenrel 6.2.9 crash on boot when retbleed=stuff is enbaled Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: kernel-bugs(a)opensuse.org Reporter: alessandro.sturniolo(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 866098 --> http://bugzilla.opensuse.org/attachment.cgi?id=866098&action=edit First crash After today updates, I rebooted my system to apply new kernel 6.2.9, and it don't boot anymore. I had done a little investigation, and I found that retbleed=stuff in my kernel command line is the cause of this crashes at boot with this kernel version. With previous kernel versions I never had issues. On logs, the system, was unable to write anything, so I shot some photos with my phone (see attachments), but the messages on video, I don't know if they can be of any interest, because they are any time different and partials. The only thing that I found interesting on this messages, is the timestamps: all messages report a timestamp of about 14-15 seconds, then the system freeze. Watching a log of a normal boot, usually, at this time, the module amdgpu is initialize. Relevant system specs: - 2x AMD Opteron 6386 SE - ASUS KGPE-D16 Motherboard - 32GB DDR3 RAM Ecc - AMD Radeon RX 6600 8GB GPU -- You are receiving this mail because: You are on the CC list for the bug.

1 4

[Bug 1210102] New: cron depends on cronie
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210102 Bug ID: 1210102 Summary: cron depends on cronie Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: opensuse(a)1.opensuse.bgcomp.co.uk QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Please remove the requirement that cron depends on cronie. I use either ntp or ntpsec. Forcing such a requirement is beyond comprehension. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1210095] New: blender fails to build on Leap 15.5 due to many openimage related errors
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210095 Bug ID: 1210095 Summary: blender fails to build on Leap 15.5 due to many openimage related errors Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Other Assignee: screening-team-bugs(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- Created attachment 866106 --> http://bugzilla.opensuse.org/attachment.cgi?id=866106&action=edit blender build log Blender currenly fails to build in Leap 15.5 All the build errors seem to be related to OpenImage I think it boils down to this issue [ 235s] /usr/include/OpenImageIO/platform.h:97:6: error: #error "This version of OIIO is meant to work only with C++14 and above" [ 235s] # error "This version of OIIO is meant to work only with C++14 and above" See attached build log for details or https://build.opensuse.org/package/live_build_log/openSUSE:Backports:SLE-15… -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1209741] New: pam session keyring creating during KDE GUI login not available to cifscreds
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1209741 Bug ID: 1209741 Summary: pam session keyring creating during KDE GUI login not available to cifscreds Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Normal Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: jmscdba(a)gmail.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- *** Background Info Please note that although I am reporting this bug against TW 20230324 the bug actually started occurring with builds created roughly 6 to 9 months ago. I did not submit earlier because I was having trouble with how to best document the situation to allow you to easily replicate the bug. After reading the Linux-PAM System Administrators Guide, I come up with the following steps to document the bug. I went with most recent TW build in a VM to replicate the problem so that you could easily do the same in your debugging, however, the problem occurs on all of my TW installs on other machines which have been zypper dup'd for years. There are NO changes to the newly installed system and it is using the default configuration for everything. *** Short description of the problem Based on my test case research it appears that one of the following is the source of the problem: 1) Either pam_keyinit.so is not creating the session keyring during login or it is somehow created but does not end up attached correctly to the user's GUI login session. 2) cifscreds is not reading/finding the session keyring *** Research and Steps to Recreate the problem Perform new TW build 20230324 installation As mentioned above this replicates on my other TW machines which have been update for years but I used this as a base so that all of the default configuration is in place. After installation is completed the rest of the steps are performed using my joe user logged into KDE and from a konsole prompt. keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 cifscreds add -u joe fileserver Warning: you have no persistent session keyring. cifscreds keys will not persist after this process exits. See pam_keyinit(8). Since cifscreds says there is no persistent keyring the credentials do not exist after cifscrds terminates as shown by the following: keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 Based on those results it "appears" that either cifscreds is not finding the session keyring and therefore that is the problem OR pam_keyinit.so is somehow not creating a new session keyring ( but it seems to be creating it based on the above ) or it is creating in a way that is not seen by the cifscreds program. Since cifsceds is unable to add the user credentials to the session keyring and have them persist this means that the user cannot access CIFS shares which have been mounted with the multiuser mount option. In testing further I tried the following: Show starting point keyrings again keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 900237848 --alswrv 1000 65534 keyring: _uid_ses.1000 725340159 --alswrv 1000 65534 \_ keyring: _uid.1000 Create a new session keyring using: keyctl session Joined session keyring: 446515518 Show keyring state after creating new one keyctl show @u Keyring 725340159 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 446515518 --alswrv 1000 1000 keyring: _ses Attempt to add credentials to newly created keyring cifscreds add -u joe fileserver No warning is displayed and credentials are added to the newly created session keyring keyctl show @s Keyring 446515518 --alswrv 1000 1000 keyring: _ses 480791877 ----sw-v 1000 1000 \_ logon: cifs:a:192.168.1.1 User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Note that I did not include the mount steps ( done as root ) because they are not part of the problem, as the real issue is with the session keyring not being available when cifscreds is run. My initial thought that something was wrong with cifscreds, however, the following test seems to confirm that the actual problem is with the PAM configuration and how pam_keyinit.so is creating the session keyring when logging into the KDE GUI. To perform this test to demonstrate that: Reboot the machine to start clean Instead of logging into KDE GUI press Ctrl+Alt+F1 to get a console. login keyctl show @u Keyring 766463839 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 576175083 --alswrv 1000 1000 keyring: _ses 766463839 --alswrv 1000 65534 \_ keyring: _uid.1000 cifscreds add -u joe fileserver No warning is displayed and credentials are successfully added keyctl show @u Keyring 766463839 --alswrv 1000 65534 keyring: _uid.1000 keyctl show @s Keyring 576175083 --alswrv 1000 1000 keyring: _ses 766463839 --alswrv 1000 65534 \_ keyring: _uid.1000 673617333 ----sw-v 1000 1000 \_ logon: cifs:a:192.168.1.1 User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Since the session keying and cifscreds work correctly from the tty console but do NOT when you log into the KDE GUI and do the exact same thing it would appear that something is wrong with how pam_keyinit is creating the session keyring and it being available in when logging into the GUI. I have tried varies other tests to see if I could "fix" the default pam config to resolve the issue which did not work. As I final test I tried the following: NOTE: I understand that we should NOT modify the /etc/pam.d/common-*-pc files and I only did this as a test to see if it resolved the issue and recognize that the real fix is/may be something totally different. Modify /etc/pam.d/common-session-pc to add the following to the end session optional pam_keyinit.so revoke force reboot login to KDE gui cifscreds add -u joe fileserver No warning is displayed and credentials are successfully added User joe can now successfully access the mounted multiuser CIFS shares using the credentials that it retrieves from session keyring. Other research grep -ir 'pam_keyinit.so' /etc/pam.d/* /usr/lib//pam.d/* Shows that it is included in MANY pam config files man pam_keyinit.so says The pam_keyinit PAM module ensures that the invoking process has a session keyring other than the user default session keyring. In order to allow other PAM modules to attach tokens to the keyring, this module provides both an auth (limited to pam_setcred(3) and a session component. The session keyring is created in the module called. Moreover this module should be included as early as possible in a PAM configuration. man cifscreds NOTES say The cifscreds utility requires a kernel built with support for the login key type. That key type was added in v3.3 in mainline Linux kernels. Since cifscreds adds keys to the session keyring, it is highly recommended that one use pam_keyinit to ensure that a session keyring is established at login time. *** Conclusion It appears that the session keyring is being creating improperly during GUI login such that cifscreds cannot use it, possibly it is not attached to the correct process ? This item on kernel org is from 2012 !!! https://patchwork.kernel.org/project/cifs-client/patch/1342704916-2224-1-gi… Seems to describe the problem I am seeing and also demonstrated how the issue does not exist at the tty console ( Ctrl+Alt+F1 ) but did when done from the GUI ( xfec4 in that case ) they have the same issue I am reporting. In one of the comments where somebody tested on a fairly stock Fedora 17 they said An excellent question. I see the same behavior on a fairly stock Fedora 17 host too. I can only assume that the actual desktop session is ending up with a different keyring session than gdm had. It sure seems like that old issue is exactly what I am seeing here since the Ctrl+Alt+F1 console does not have the issue and the GUI login does. The bottom line is that something is wrong with the default pam config for pam_keyinit.so when you log into the KDE GUI such that the session keyring is not seen/available to cifscreds and adding to common-session-pc works around the issue for now but may not be the best solution or could have other security issues. I suspect that the real solution is to make sure that KDE GUI login has the session keyring created in the same way and attached to the same process as the Ctrl+Alt+F1 login. I am happy to perform any other tests or gather other information just provide the steps for whatever other information you need. Hopefully this very detailed bug report provides you with most of the legwork completed to debug and now we only need the fix created. -- You are receiving this mail because: You are on the CC list for the bug.

1 27

[Bug 1209970] Trimmed "Leap" logo on the default wallpaper
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209970 https://bugzilla.suse.com/show_bug.cgi?id=1209970#c2 --- Comment #2 from Takashi Iwai <tiwai(a)suse.com> --- (In reply to Maurizio Galli from comment #1) > I think it's better to open an issue here: > https://github.com/openSUSE/artwork Is the file copied directly from there? Also, a part of the problem is that 1600x1200 wallpaper is used even though we have 1920x1200 wallpaper provided. It's likely because /usr/share/wallpapers/xfce has only a single default? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1198621] New: systemd-boot: mach bunt
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1198621 Bug ID: 1198621 Summary: systemd-boot: mach bunt Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Bootloader Assignee: snwint(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Blocks: 1198583 Found By: --- Blocker: --- If we go for systemd-boot we need it to look nice. How about gfxboot for it? :-) -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1209729] After update system no longer able to boot because mount sysroot unknown filesystem type jfs
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1209729 https://bugzilla.suse.com/show_bug.cgi?id=1209729#c13 Gerald Pfeifer <gp(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |gp(a)suse.com --- Comment #13 from Gerald Pfeifer <gp(a)suse.com> --- (In reply to sachse(a)gmx.net from comment #11) > [...] At openSUSE we strive to be a community that is welcoming, friendly, and considerate. Comment #11 (and comment #2) are not in line with our principles and our Code of Conduct, <https://en.opensuse.org/Code_of_Conduct>. In particular please refrain from threatening others. This is a friendly warning; if necessary we will take further steps such as removing write access to lists or tools. Gerald, on behalf of the openSUSE Board -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1208394] AUDIT-0: ruby3.1-rubygem-d-installer: follow-up audit of D-Bus setup (separate D-Bus design)
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1208394 https://bugzilla.suse.com/show_bug.cgi?id=1208394#c7 --- Comment #7 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- So from your description in comment 4 it sounds like the addition a D-Bus instance is kind of private to the two containers for backend and the web components. Is that true? Can the UNIX domain socket be accessed from the host system otherwise? Of course the interface of d-installer can be accessed indirectly via the web component, I suppose. Will this listen on localhost or also on remotely accessible network interfaces by default? The separate D-Bus instance only shared by the two containers sounds like it improves the isolation on D-Bus level so I have no problem with that. Although the use of containers on initrd level sounds pretty complex, design wise. What I meant by asking if you are blocked by us is whether you are hitting any whitelisting restrictions that we need to fix? But I don't think so. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1210051] New: Improve YaST Memory Consumption
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

https://bugzilla.suse.com/show_bug.cgi?id=1210051 Bug ID: 1210051 Summary: Improve YaST Memory Consumption Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: CONFIRMED Severity: Normal Priority: P5 - None Component: YaST2 Assignee: jreidinger(a)suse.com Reporter: jreidinger(a)suse.com QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- It is shown clearly in Agama, that yast eats quite chunk of memory especially if it runs in multiple instance. -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1210088] New: [SELinux] geoclue denied watch for /etc
by bugzilla_noreply＠suse.com 04 Apr '23

04 Apr '23

http://bugzilla.opensuse.org/show_bug.cgi?id=1210088 Bug ID: 1210088 Summary: [SELinux] geoclue denied watch for /etc 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: filippo.bonazzi(a)suse.com QA Contact: security-team(a)suse.de Found By: --- Blocker: --- Operating System: MicroOS Desktop SELinux status, mode and policy name: enforcing, targeted SELinux policy version and repository: Repository : openSUSE-Tumbleweed-Oss Name : selinux-policy-targeted Version : 20230321-1.1 Arch : noarch Vendor : openSUSE Installed Size : 24.0 MiB Installed : Yes (automatically) Status : up-to-date The software (incl. version) that is affected by the SELinux issue and the error message: geoclue 2.7.0, doesn't seem broken but still the below AVCs pop up SELinux Audit log: ``` type=AVC msg=audit(1680601975.345:68): avc: denied { watch } for pid=1056 comm="geoclue" path="/etc" dev="overlay" ino=46973 scontext=system_u:system_r:geoclue_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0 type=AVC msg=audit(1680601979.151:71): avc: denied { watch } for pid=1056 comm="gmain" path="/etc" dev="overlay" ino=46973 scontext=system_u:system_r:geoclue_t:s0 tcontext=system_u:object_r:etc_t:s0 tclass=dir permissive=0 ``` The second AVC is repeated multiple times, not sure if periodic or if it depends on e.g. user action -- You are receiving this mail because: You are on the CC list for the bug.

1 2