May 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1171065] New: Dracut complains about missing crc32c module with kernel-default-base
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1171065 Bug ID: 1171065 Summary: Dracut complains about missing crc32c module with kernel-default-base Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: Kernel Assignee: jeos-internal(a)suse.de Reporter: fvogt(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- When running mkinitrd with kernel-default-base installed, this happens: dracut: *** Including module: suse-initrd *** dracut-install: Failed to find module 'crc32c' dracut: FAILED: /usr/lib/dracut/dracut-install -D /var/tmp/dracut.axJFbC/initramfs -H -N i2o_scsi --kerneldir /lib/modules/5.6.6-1-default/ -m crc32c It's because of /etc/modprobe.d/00-system.conf: # libcrc32c calls crypto_alloc_shash("crc32c", 0, 0), which results in a # request_module("crc32c"), but that dependency is not seen by modpost/depmod # https://bugzilla.novell.com/552443 # SUSE INITRD: libcrc32c REQUIRES crc32c It's not fully clear what crc32c is and what it's used for, but I assume it's an alias provided by hardware-specific optimized implementations of crc32c. If this is the case, it would definitely fit into the set of modules provided by kernel-default-base. Question is how this would have to be added, would mentioning crc32c work or do the actual module names need to be added in %ifarch sections? -- You are receiving this mail because: You are on the CC list for the bug.

1 9

[Bug 1171176] New: Please enable strongswan bypass-lan plugin
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1171176 Bug ID: 1171176 Summary: Please enable strongswan bypass-lan plugin Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.1 Hardware: Other OS: Other Status: NEW Severity: Enhancement Priority: P5 - None Component: Network Assignee: screening-team-bugs(a)suse.de Reporter: teemu.lahtela(a)live.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0 Build Identifier: Could you add configure option "--enable-bypass-lan" to the strongswan.spec. And the bypass-lan.conf and libstrongswan-bypass-lan.so need to be added into the spec file as well. Reproducible: Always -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1171174] New: security enhancement: no setuid
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1171174 Bug ID: 1171174 Summary: security enhancement: no setuid Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: MicroOS Assignee: kubic-bugs(a)opensuse.org Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- setuid binaries are a potential attack vector for privilege escalation. MicroOS with it's limited scope has chance to close that hole by default and not ship any binaries with elevated privileges by default. Ie set the default level to "paranoid". This will prevent unprivileged (system) users from potentially exploiting - shadow suite tools like passwd, chsh etc - pam helpers unix{,2}_chkpwd - wall, write - clockdiff, ping - dbus-daemon-launch-helper - su - sudo - mount -- You are receiving this mail because: You are on the CC list for the bug.

1 1

[Bug 1171164] AUDIT-0: permissions: %_libexecdir changes from /usr/lib to /usr/libexec, affects multiple entries
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1171164 http://bugzilla.suse.com/show_bug.cgi?id=1171164#c2 --- Comment #2 from Dominique Leuenberger <dimstar(a)opensuse.org> --- (In reply to Matthias Gerstner from comment #1) > Doing this for dbus-daemon-launch-helper is not hard. But how can we easily > assemble a list of affected packages? Is this already live in Factory? No; it can't go live, as packages would not build properly or even break on runtime; this is currenly in Staging:A Not all build failures there are due to this though. I can add more of those failures here as they appear. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1169703] [doc] Small mistakes in 389 server setup documentation
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1169703 Frank Sundermeyer <fs(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|fs(a)suse.com |taroth(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1171173] New: permissions: paranoid mode has setuid binaries
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.opensuse.org/show_bug.cgi?id=1171173 Bug ID: 1171173 Summary: permissions: paranoid mode has setuid binaries Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.2 Hardware: Other OS: Other Status: NEW Severity: Major Priority: P5 - None Component: Security Assignee: security-team(a)suse.de Reporter: lnussel(a)suse.com QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- /usr/bin/newgidmap and /usr/bin/newuidmap have setuid bits in level paranoid. paranoid is meant to switch off all bits without exception. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1171164] AUDIT-0: permissions: %_libexecdir changes from /usr/lib to /usr/libexec, affects multiple entries
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1171164 http://bugzilla.suse.com/show_bug.cgi?id=1171164#c1 Matthias Gerstner <matthias.gerstner(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matthias.gerstner(a)suse.com Summary|permission handling: |AUDIT-0: permissions: |%_libexecdir changes from |%_libexecdir changes from |/usr/lib to /usr/libexec |/usr/lib to /usr/libexec, | |affects multiple entries --- Comment #1 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- Doing this for dbus-daemon-launch-helper is not hard. But how can we easily assemble a list of affected packages? Is this already live in Factory? -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1171126] [doc] 10.5.1 Customizing Unit Files
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1171126 Frank Sundermeyer <fs(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Whiteboard| |https://trello.com/c/QChT1p | |s1/ -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1171115] AUDIT-0: polkit-default-privs: org.freedesktop.login1.* in restrictive profile: KDE hangs on logout when choosing "shut down"
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1171115 http://bugzilla.suse.com/show_bug.cgi?id=1171115#c2 --- Comment #2 from Christian Boltz <suse-beta(a)cboltz.de> --- (In reply to Matthias Gerstner from comment #1) > What exactly happens when you're trying to shut down? Is the graphical > session locked up? All running programs including the task bar get closed, and the desktop goes black. In the end, I have a black screen with working mouse pointer - and Ctrl-Alt-Backspace seems to be the only option to kill the session. > Apart from that it is open for debate whether it is useful to deny locally > logged in users to reboot or shutdown a system even in the restrictive polkit > setting. I guess denying that is a rather special use case for kiosk systems > or similar situations. As I already mentioned - after logging out, I can shutdown or reboot the system from sddm (without entering a password) which makes denying that to KDE a bit funny ;-) > I'd say that network-control and mount/umount actions are restricted is > intentional for the "restrictive" polkit profile. You can always override > individual settings using the "local" polkit profile in > /etc/polkit-default-privs.local. No problem - I mentioned these things "for completeness", and fully understand that there are reasons to have them restricted in secure mode. > Actually the security would like to better differentiate between system roles > like "workstation", "multiuser system" and "server". This would allow to > provide better defaults. This would require deep rooting changes in the > distribution, however, that aren't easy to implement. To make it even more complicated - how would you categorize my laptop? Right now, I'm logged in in KDE - and in the background I have Apache, MySQL etc. running ;-) I'm afraid the only sane (and at the same time easy-to-implement) option is to handle this as a manual setting, for example PERMISSION_SECURITY="secure desktop local" (IMHO "secure" could include the server bits, and "desktop" could be used to relax some things like allowing to mount USB sticks.) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1168914] New: RAID module uses metadata=1.0 and therefore can't use journal feature for RAID5
by bugzilla_noreply＠novell.com 05 May '20

05 May '20

http://bugzilla.suse.com/show_bug.cgi?id=1168914 Bug ID: 1168914 Summary: RAID module uses metadata=1.0 and therefore can't use journal feature for RAID5 Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: YaST2 Assignee: yast2-maintainers(a)suse.de Reporter: psikodad(a)gmx.de QA Contact: jsrain(a)suse.com Found By: --- Blocker: --- Summary: yast partitioner creates raid devices always with "metadata=1.0" and therefore it's not possible to add a journal to a RAID5 device. Workaround: Create the RAID5 manually, because then the default metadata version 1.2 is used, which supports journal. When I create a new RAID5 with YaST2 partitioner (storage-ng), then the raid version (metadata) is always 1.0. In fact it's hard coded in file libstorage-ng-master/storage/Devices/MdImpl.cc: string cmd_line = MDADM_BIN " --create " + quote(get_name()) + " --run --level=" + boost::to_lower_copy(toString(md_level), locale::classic()) + " --metadata=1.0" " --homehost=any"; A few years ago mdadm got a new feature to fight the "write hole" of RAID5: journaling. see https://www.kernel.org/doc/Documentation/md/raid5-cache.txt I would like the test it (--add-journal), but it's not working: # mdadm --detail /dev/md127 /dev/md127: Version : 1.0 Creation Time : Tue Apr 7 22:39:34 2020 Raid Level : raid5 Array Size : 16776960 (16.00 GiB 17.18 GB) Used Dev Size : 8388480 (8.00 GiB 8.59 GB) Raid Devices : 3 ... Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 3 8 48 2 active sync /dev/sdd # mdadm --manage /dev/md127 --readonly --add-journal /dev/sde mdadm: Failed to hot add /dev/sde as journal, please try restart /dev/md127. # mdadm --stop /dev/md127 mdadm: stopped /dev/md127 # mdadm --assemble /dev/md127 /dev/sd[bcd] mdadm: /dev/md127 has been started with 3 drives. # mdadm --manage /dev/md127 --readonly --add-journal /dev/sde mdadm: Failed to hot add /dev/sde as journal, please try restart /dev/md127. ------------ However, it works when metadata=1.2 (which is the default for mdadm) tw2019:/home/dom # mdadm --stop /dev/md127 mdadm: stopped /dev/md127 tw2019:/home/dom # mdadm --create /dev/md127 --level=5 --raid-devices=3 /dev/sd[bcd] mdadm: /dev/sdb appears to be part of a raid array: level=raid5 devices=3 ctime=Tue Apr 7 22:39:34 2020 mdadm: /dev/sdc appears to be part of a raid array: level=raid5 devices=3 ctime=Tue Apr 7 22:39:34 2020 mdadm: /dev/sdd appears to be part of a raid array: level=raid5 devices=3 ctime=Tue Apr 7 22:39:34 2020 Continue creating array? y mdadm: Defaulting to version 1.2 metadata mdadm: array /dev/md127 started. # mdadm --detail /dev/md127 /dev/md127: Version : 1.2 Creation Time : Tue Apr 7 22:47:35 2020 Raid Level : raid5 Array Size : 16758784 (15.98 GiB 17.16 GB) Used Dev Size : 8379392 (7.99 GiB 8.58 GB) Raid Devices : 3 ... Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 3 8 48 2 active sync /dev/sdd # mdadm --manage /dev/md127 --readonly --add-journal /dev/sde mdadm: Journal added successfully, making /dev/md127 read-write mdadm: added /dev/sde # mdadm --detail /dev/md127 /dev/md127: Version : 1.2 Creation Time : Tue Apr 7 22:47:35 2020 Raid Level : raid5 Array Size : 16758784 (15.98 GiB 17.16 GB) Used Dev Size : 8379392 (7.99 GiB 8.58 GB) Raid Devices : 3 Total Devices : 4 Persistence : Superblock is persistent Update Time : Tue Apr 7 22:48:48 2020 State : clean Active Devices : 3 Working Devices : 4 Failed Devices : 0 Spare Devices : 0 Layout : left-symmetric Chunk Size : 512K Consistency Policy : journal Name : tw2019:127 (local to host tw2019) UUID : 5dec6792:8109c604:970842a7:44f0d9e8 Events : 19 Number Major Minor RaidDevice State 0 8 16 0 active sync /dev/sdb 1 8 32 1 active sync /dev/sdc 3 8 48 2 active sync /dev/sdd 4 8 64 - journal /dev/sde => Use the default metadata (1.2) for new RAID devices. For RAID1 there could be some reasons to stick with version 1.0. See also : yast-storage-ng-master/src/lib/y2storage/boot_requirements_strategies/uefi.rb # EFI in RAID can work, but it is not much reliable. # See bsc#1081578#c9, FATE#322485, FATE#314829 # - RAID metadata must be somewhere where it will not interfere with UEFI reading # the disk. libstorage-ng currently uses "mdadm --metadata=1.0" which is OK # - The partition boot flag must be on # - The partition RAID flag must be on (but setting it resets the boot flag) -- You are receiving this mail because: You are on the CC list for the bug.

1 6