November 2023 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1216537] New: xdg-utils perl requirement
by bugzilla_noreply＠suse.com 25 Jul '24

25 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1216537 Bug ID: 1216537 Summary: xdg-utils perl requirement Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: X11 Applications Assignee: simonf.lees(a)suse.com Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de CC: jslaby(a)suse.com Target Milestone: --- Found By: --- Blocker: --- xdg-utils requires perl via /usr/bin/xdg-screensaver. On minimal systems we'd like to avoid any extra script interpreters. Any chance to avoid using perl there? -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1213659] New: VUL-0: CVE-2023-38496: apptainer: Ineffective privileges drop when requesting container network
by bugzilla_noreply＠suse.com 22 Jul '24

22 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1213659 Bug ID: 1213659 Summary: VUL-0: CVE-2023-38496: apptainer: Ineffective privileges drop when requesting container network Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: Other URL: https://smash.suse.de/issue/373431/ OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: cgoll(a)suse.com Reporter: gianluca.gabrielli(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Apptainer is an open source container platform. Version 1.2.0-rc.2 introduced an ineffective privilege drop when requesting container network setup, therefore subsequent functions are called with root privileges, the attack surface is rather limited for users but an attacker could possibly craft a starter config to delete any directory on the host filesystems. A security fix has been included in Apptainer 1.2.1. There is no known workaround outside of upgrading to Apptainer 1.2.1. References: http://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-38496 https://bugzilla.redhat.com/show_bug.cgi?id=2226582 https://www.cve.org/CVERecord?id=CVE-2023-38496 http://www.cvedetails.com/cve/CVE-2023-38496/ https://github.com/apptainer/apptainer/pull/1523 https://github.com/apptainer/apptainer/pull/1578 https://github.com/apptainer/apptainer/security/advisories/GHSA-mmx5-32m4-w… -- You are receiving this mail because: You are on the CC list for the bug.

1 5

[Bug 1217414] New: changing default umask for new users homedir sets the current umask for ALL users including root
by bugzilla_noreply＠suse.com 19 Jul '24

19 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217414 Bug ID: 1217414 Summary: changing default umask for new users homedir sets the current umask for ALL users including root Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: joergboe44(a)googlemail.com QA Contact: jsrain(a)suse.com Target Milestone: --- Found By: --- Blocker: --- When I change the default umask for new users home dir, the umask for all users (including root) is changed after login. This is not what I expect and may be dangerousö. OS version: openSUSE Tumbleweed 20231121 Steps to reproduce: 1. Check the umask setting for a user or root: su --login test2 Password: test2@localhost:~> umask 0022 2. Change the umask for home directory of new users: Yast->User and group management->Defaults for new users: Change umask for home directory to 002 3. Login as a user or root e.g 'su --login' su --login test2 Password: test2@localhost:~> umask 0002 The umask is changed for all users. This bug is almost the same as in Bugzilla – Bug 606249. But the behavior is obviously changed since then. In the current Tumbleweed version the YAST changes the UMASK in file /etc/login.defs.d/70-yast.defs And this seems to be enough to change the umask for the next login. -- You are receiving this mail because: You are on the CC list for the bug.

1 3

[Bug 1217306] New: distrobox stuck at starting container
by bugzilla_noreply＠suse.com 18 Jul '24

18 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217306 Bug ID: 1217306 Summary: distrobox stuck at starting container Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.6 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Containers Assignee: containers-bugowner(a)suse.de Reporter: lubos.kocman(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 870843 --> https://bugzilla.suse.com/attachment.cgi?id=870843&action=edit few seconds of strace -p 5212 2>&1 | tee /tmp/strace-out.log Following happened on Leap 15.6 lkocman@localhost:~/Workspace> distrobox enter mirror Error: no such container mirror Cannot find container mirror Creating the container with command: /usr/bin/distrobox-create -i registry.opensuse.org/opensuse/distrobox:latest -n mirror Trying to pull registry.opensuse.org/opensuse/distrobox:latest... Getting image source signatures Copying blob 942e611a39d7 done Copying blob 1517c1ea8bb6 done Copying config 8372decf75 done Writing manifest to image destination 8372decf752e74665fcb94d31b9b378dd1790233ab36b03d37f63dac462e0fbc Creating 'mirror' using image registry.opensuse.org/opensuse/distrobox:latest [ OK ] Distrobox 'mirror' successfully created. To enter, run: distrobox enter mirror Container mirror is not running. Starting container mirror run this command to follow along: podman logs -f mirror Starting container... # Stuck here for 30 minutes or so lkocman@localhost:~/Workspace> ps aux | grep distro lkocman 5210 0.0 0.0 11096 3328 pts/0 S+ 08:13 0:00 /bin/sh /usr/bin/distrobox enter mirror lkocman 5212 2.1 0.0 11224 3840 pts/0 S+ 08:13 0:53 /bin/sh /usr/bin/distrobox-enter mirror lkocman 27424 0.0 0.0 8212 2304 pts/1 S+ 08:56 0:00 grep --color=auto distro Strace seems that the program itself is busy Not sure if this isn't an issue rt_sigprocmask(SIG_SETMASK, [], NULL, 8) = 0 --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=27782, si_uid=1000, si_status=0, si_utime=2, si_stime=0} --- wait4(-1, 0x7ffc3cd5bbd0, WNOHANG, NULL) = -1 ECHILD (No child processes) rt_sigreturn({mask=[]}) = 0 openat(AT_FDCWD, "/home/lkocman/.cache/.mirror.fifo", O_RDONLY) = 3 fcntl(0, F_GETFD) = 0 fcntl(0, F_DUPFD, 10) = 10 fcntl(0, F_GETFD) = 0 fcntl(10, F_SETFD, FD_CLOEXEC) = 0 dup2(3, 0) = 0 close(3) = 0 ioctl(0, TCGETS, 0x7ffc3cd5c4f0) = -1 ENOTTY (Inappropriate ioctl for device) -- You are receiving this mail because: You are on the CC list for the bug.

1 22

[Bug 1213595] New: Live ISO does not creates Persistent storage
by bugzilla_noreply＠suse.com 16 Jul '24

16 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1213595 Bug ID: 1213595 Summary: Live ISO does not creates Persistent storage Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Live Medium Assignee: fvogt(a)suse.com Reporter: sehsuvarselmanoglu(a)hotmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868398 --> https://bugzilla.suse.com/attachment.cgi?id=868398&action=edit 7z File for some logs Hi, I downloaded OpenSUSE Leap ISO (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.40-Media.iso) at 08/06/2023 (as soon as released) then I “dd” to USB stick and plugged to computer and it worked fine. At first boot, it did create the persistent storage cow (boot.log : [ 22.002982] dracut-initqueue[877]: mke2fs 1.46.4 (18-Aug-2021) ) Few days later I download again this time build number was different (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.57-Media.iso). At first boot, it did not create persistent storage. dracut says (boot.log : [ 21.489260] dracut-initqueue[769]: Warning: Falling back to temporary overlay) same as the new release (openSUSE-Leap-15.5-KDE-Live-x86_64-Build10.73-Media.iso) Any release after 10.40 does not creates persistent storage (neither 10.53 nor 10.73) I tried with different CPU (AMD, Core Duo, I5) and different USB stick (4GB 8GB 16GB and 32GB) even with different port (USB2 USB3) with different USB s and so on. No matter what I tried don't work. Releases after 10.40 (10.57 or 10.73) do not creates the persistent storage. So I open discussion on the forums.opensuse.org and someone suggested that I need to open bug report. and he/she wrote "It is not something you can fix without recreating initrd. The script that is used here comes from kiwi dracut module.". I also add the 7zip file for each ISO "....10.40", "...10.57", "...10.73" that contains some log files. "boot.log" : "sudo cp /var/log/boot.log" "boot.msg" : "cp /var/log/boot.msg" "dmesg.txt" : Output of "dmesg" right after the first boot "fdisk.txt" : 0utput of "fdisk -l" right after first boot "journal.txt" : Output of "sudo journalctl --no-pager --full -b" Thank you very much. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1214353] New: mhi: Enabling broadband connecting not working
by bugzilla_noreply＠suse.com 16 Jul '24

16 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1214353 Bug ID: 1214353 Summary: mhi: Enabling broadband connecting not working Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Normal Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: holgi(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 868851 --> https://bugzilla.suse.com/attachment.cgi?id=868851&action=edit hwinfo.txt When trying to use broadband connecting with network manager, I can not get beyond entering SIM code - starting connection does not work System Slot: #36 Designation: "M.2 WWAN Connector (J3702)" Type: 0xa6 (Other) Bus Width: 0x08 (Other) Status: 0x03 (Available) Length: 0x04 (Long) Slot ID: 4 Characteristics: 0x0704 (3.3 V, PME#, Hot-Plug) -- You are receiving this mail because: You are on the CC list for the bug.

1 12

[Bug 1214364] New: net-snmp: new release 5.9.4
by bugzilla_noreply＠suse.com 09 Jul '24

09 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1214364 Bug ID: 1214364 Summary: net-snmp: new release 5.9.4 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Basesystem Assignee: abergmann(a)suse.com Reporter: abergmann(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- https://github.com/net-snmp/net-snmp/blob/v5.9.4/CHANGES *5.9.4*: IMPORTANT: SNMP over TLS and/or DTLS are not functioning properly in this release with various versions of OpenSSL and will be fixed in a future release. libsnmp: - Remove the SNMP_SWIPE_MEM() macro Remove this macro since it is not used in the Net-SNMP code base. - DISPLAY-HINT fixes - Miscellanious improvements to the transports - Handle multiple oldEngineID configuration lines - fixes for DNS names longer than 63 characters agent: - Added a ignoremount configuration option for the HOST-MIB - disallow SETs with a NULL varbind - fix the --enable-minimalist build apps: - snmpset: allow SET with NULL varbind for testing - snmptrapd: improved MySQL logging code general: - configure: Remove -Wno-deprecated as it is no longer needed - miscellanious ther bug fixes, build fixes and cleanups -- You are receiving this mail because: You are on the CC list for the bug.

1 6

[Bug 1217688] New: mariadb: a table is missing inserted entries from concurrent processes
by bugzilla_noreply＠suse.com 08 Jul '24

08 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217688 Bug ID: 1217688 Summary: mariadb: a table is missing inserted entries from concurrent processes Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other URL: https://jira.mariadb.org/browse/MDEV-32871 OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Other Assignee: danilo.spinella(a)suse.com Reporter: jslaby(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- Created attachment 871082 --> https://bugzilla.suse.com/attachment.cgi?id=871082&action=edit db inserter With mariadb: 11.0.2, 11.1.2 and 11.1.3 (from server:database): From my c++ code, using connector-c, I do: SET autocommit=0 CREATE TABLE IF NOT EXISTS sources(id INTEGER AUTO_INCREMENT PRIMARY KEY, src VARCHAR(1024) NOT NULL UNIQUE) INSERT IGNORE INTO sources(src) VALUES (?) START TRANSACTION And then a lot of: INSERT IGNORE INTO sources(src) VALUES ('src-003431-00001') src is composed of pid and values from 0 to 49. So they are all unique. Finally, I do: COMMIT If I run 10 instances in parallel like: for aa in {1..10} ; do ./db & done ; wait I see: select count(id), substr(src,5,6) as sss from sources group by sss; +-----------+--------+ | count(id) | sss | +-----------+--------+ | 50 | 003430 | | 50 | 003431 | | 50 | 003432 | | 40 | 003433 | | 50 | 003434 | | 50 | 003435 | | 50 | 003436 | | 50 | 003437 | | 50 | 003438 | | 50 | 003439 | +-----------+--------+ I.e. Some of pids stored only last 40 values, numbers 0..9 are missing in the table: select src from sources where src like '%003433%' order by src ; +------------------+ | src | +------------------+ | src-003433-00010 | | src-003433-00011 | | src-003433-00012 | | src-003433-00013 | | src-003433-00014 | | src-003433-00015 | | src-003433-00016 | | src-003433-00017 | | src-003433-00018 | | src-003433-00019 | | src-003433-00020 | | src-003433-00021 | | src-003433-00022 | | src-003433-00023 | | src-003433-00024 | | src-003433-00025 | | src-003433-00026 | | src-003433-00027 | | src-003433-00028 | | src-003433-00029 | | src-003433-00030 | | src-003433-00031 | | src-003433-00032 | | src-003433-00033 | | src-003433-00034 | | src-003433-00035 | | src-003433-00036 | | src-003433-00037 | | src-003433-00038 | | src-003433-00039 | | src-003433-00040 | | src-003433-00041 | | src-003433-00042 | | src-003433-00043 | | src-003433-00044 | | src-003433-00045 | | src-003433-00046 | | src-003433-00047 | | src-003433-00048 | | src-003433-00049 | +------------------+ Is this a bug in my program (attached) or the db? If I look into the general log, I see the inserts which apparently did not get into the table: grep src-003433 /tmp/glog 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00000') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00001') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00002') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00003') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00004') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00005') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00006') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00007') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00008') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00009') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00010') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00010') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00011') 24 Execute INSERT IGNORE INTO sources(src) VALUES ('src-003433-00012') Note also the repeated inserts. They come from a deadlock, so I repeat the exec in a loop (see the code). Dockers with mariadb:latest (11.2.2) mariadb:11.1.3 mariadb:11.1.2 all run FINE too. -- You are receiving this mail because: You are on the CC list for the bug.

1 14

[Bug 1217309] New: [RPi4] rebootmgr does not reboot the system
by bugzilla_noreply＠suse.com 05 Jul '24

05 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1217309 Bug ID: 1217309 Summary: [RPi4] rebootmgr does not reboot the system Classification: openSUSE Product: openSUSE Leap Micro Version: 5.5 Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Transactional Update Assignee: lubos.kocman(a)suse.com Reporter: mbrugger(a)suse.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- When trying to reboot the system, system services is shut down but no reboot happens. That leaves the system in a state without networking. > printi:~ # rebootmgrctl get-strategy > Reboot strategy: best-effort > printi:~ # rebootmgrctl get-window > Maintenance window is set to *-*-* 03:30:00, lasting 01h30m. > printi:~ # rebootmgrctl is-active > RebootMgr is active journalctl output can be found here: https://paste.opensuse.org/pastes/c0c9f158cadd Interestingly running > rebootmgrctl reboot now does actually reboot the system. -- You are receiving this mail because: You are on the CC list for the bug.

1 20

[Bug 1216564] New: Missing directory /usr/share/ca-certificates for charon
by bugzilla_noreply＠suse.com 04 Jul '24

04 Jul '24

https://bugzilla.suse.com/show_bug.cgi?id=1216564 Bug ID: 1216564 Summary: Missing directory /usr/share/ca-certificates for charon Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.5 Hardware: x86-64 OS: openSUSE Leap 15.5 Status: NEW Severity: Major Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: keitarobr(a)gmail.com QA Contact: qa-bugs(a)suse.de Target Milestone: --- Found By: --- Blocker: --- charon-nm is looking for certificates at /usr/share-ca-certificates, but this directory does not exist. Thus it can't validate a valid certificate for an IPSec/IKEv2 VPN server (does not find the GlobalSign root certificates). I solved the issue issuing the following command: sudo ln -s /var/lib/ca-certificates/pem /usr/share/ca-certificates -- You are receiving this mail because: You are on the CC list for the bug.

1 2