October 2020 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1176091] Microphone not working / sof-firmware kernel 5.8.4
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1176091 https://bugzilla.suse.com/show_bug.cgi?id=1176091#c7 --- Comment #7 from jean-christophe baptiste <jc(a)phocean.net> --- (In reply to Takashi Iwai from comment #6) > FWIW, the SOF firmware 1.6-rc3 package is found at OBS home:tiwai:sof-1.6 > repo > > http://download.opensuse.org/repositories/home:/tiwai:/sof-1.6/ > openSUSE_Tumbleweed/ Not working either. I found a thread similar to mine where someone mentioned it to be solved with Pulseaudio versio 13.99: https://bbs.archlinux.org/viewtopic.php?id=257433 That's something I am going to try. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1174593] pam_xauth(.so) module is extremly slow on Leap 15.2
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1174593 https://bugzilla.suse.com/show_bug.cgi?id=1174593#c28 Josef Möllers <josef.moellers(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|werner(a)suse.com |kstreitova(a)suse.com Flags| |needinfo?(kstreitova(a)suse.c | |om) --- Comment #28 from Josef Möllers <josef.moellers(a)suse.com> --- (In reply to Josef Möllers from comment #26) > Hm ... when collecting this stuff, it occurred to me that pam_xauth could > retrieve the old user name prior to calling pam_get_user() ... stay tuned ... No show: pam_syslog(pamh, LOG_NOTICE, "Getting old user name"); -> Getting old user name if (pam_get_item(pamh, PAM_USER, &old_username) != PAM_SUCCESS) { : } pam_syslog(pamh, LOG_NOTICE, "old user name=%s", old_username); -> old user name=root There is next to nothing preceding this (just some options parsing), so PAM_USER is already set to root and pam_xauth will have a hard time finding the invoking user. So best discuss this with sudo's bugwoner: Kristýna Streitová <kstreitova(a)suse.com> -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1176742] AUDIT-0: plasma5-disks (suse-dbus-unauthorized-service, polkit-untracked-privilege)
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1176742 https://bugzilla.suse.com/show_bug.cgi?id=1176742#c4 --- Comment #4 from Fabian Vogt <fvogt(a)suse.com> --- (In reply to Matthias Gerstner from comment #3) > (In reply to fvogt(a)suse.com from comment #1) > > I had a quick look at the helper and while it prevents arbitrary arguments > > to be passed (the absolute path has to be below /dev), this can probably be > > circumvented by sending a file descriptor over dbus and passing /dev/fd/X > > (should be predictable) as argument. > > Yes this would be possible, but it requires the attacker to open the file in > advance (i.e. he needs to have certain access rights anyway). It could be > combined with a symlink attack in the path that /dev/fd/X is pointing to. Shouldn't even be necessary. open with O_PATH doesn't require privileges like that and smartctl seems to dereference the passed path anyway... > Furthermore there is a TOCTOU race condition regarding the call to > `info.absoluteFilePath()` and the time the path is actually accessed by > smartctl. Since /dev/shm is a world writable sticky bit directory an attacker > can: > > - first place a regular file in /dev/shm/myfile > - call the org.kde.kded.smart.smartctl action for /dev/shm/myfile > - try to win the race condition by replacing /dev/shm/myfile with a symlink > at > the right time > - on success smartctl will dereference the symlink and arbitrary paths will > become possible. > - kernel symlink protection will prevent the worst > > Mostly this issue could be used for file existence tests. Since smartctl only > operates on block devices there shouldn't be much further damage involved. > > Since we are seeing these types of weak file path checks again and again I > still like to see improved code. We need to stop spreading such bad examples > in OSS code. Definitely. IIRC I've heard of a library which implements several of such primitives in a secure way, so if that's license compatible it could be used (or copied, as it's past dep freeze). I don't know where I found that anymore though, maybe you know something? > What can be done is something along the following lines: > > - use realpath() to resolve all path components of the input path > - require that the resolved path starts with /dev > - split up the path into individual path components > - open /dev with the O_PATH|O_NOFOLLOW flags and start descending down the > resolved path components using openat(), O_PATH|O_NOFOLLOW. > > for each path component: > > - perform an fstat() and inspect the owner, file type and mode. > - if the file type is other than block device or directory then an error > needs > to be returned. > - if the file is owned by a non-root user then an error needs to be returned. > - if the file is world-writable (sticky-bit directories) then an error needs > to be returned. > > - the final path component needs to be of the block device file type > - smartctl needs to be pointed to the resolved path. No path components under > attacker control should be involved. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1176793] [Build 20200921] openQA test fails in system_role y2start core dumped ppc64 (BE)
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1176793 Lukas Ocilka <locilka(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|CONFIRMED |IN_PROGRESS -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1176742] AUDIT-0: plasma5-disks (suse-dbus-unauthorized-service, polkit-untracked-privilege)
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1176742 https://bugzilla.suse.com/show_bug.cgi?id=1176742#c3 --- Comment #3 from Matthias Gerstner <matthias.gerstner(a)suse.com> --- (In reply to fvogt(a)suse.com from comment #1) > I had a quick look at the helper and while it prevents arbitrary arguments > to be passed (the absolute path has to be below /dev), this can probably be > circumvented by sending a file descriptor over dbus and passing /dev/fd/X > (should be predictable) as argument. Yes this would be possible, but it requires the attacker to open the file in advance (i.e. he needs to have certain access rights anyway). It could be combined with a symlink attack in the path that /dev/fd/X is pointing to. Furthermore there is a TOCTOU race condition regarding the call to `info.absoluteFilePath()` and the time the path is actually accessed by smartctl. Since /dev/shm is a world writable sticky bit directory an attacker can: - first place a regular file in /dev/shm/myfile - call the org.kde.kded.smart.smartctl action for /dev/shm/myfile - try to win the race condition by replacing /dev/shm/myfile with a symlink at the right time - on success smartctl will dereference the symlink and arbitrary paths will become possible. - kernel symlink protection will prevent the worst Mostly this issue could be used for file existence tests. Since smartctl only operates on block devices there shouldn't be much further damage involved. Since we are seeing these types of weak file path checks again and again I still like to see improved code. We need to stop spreading such bad examples in OSS code. What can be done is something along the following lines: - use realpath() to resolve all path components of the input path - require that the resolved path starts with /dev - split up the path into individual path components - open /dev with the O_PATH|O_NOFOLLOW flags and start descending down the resolved path components using openat(), O_PATH|O_NOFOLLOW. for each path component: - perform an fstat() and inspect the owner, file type and mode. - if the file type is other than block device or directory then an error needs to be returned. - if the file is owned by a non-root user then an error needs to be returned. - if the file is world-writable (sticky-bit directories) then an error needs to be returned. - the final path component needs to be of the block device file type - smartctl needs to be pointed to the resolved path. No path components under attacker control should be involved. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175119] while doing the autoyast an internal error occurs it says: undefined method `product_package'
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1175119 https://bugzilla.suse.com/show_bug.cgi?id=1175119#c18 --- Comment #18 from Nicolas Nattermann <opensuse-bugs(a)yalwa.com> --- Created attachment 842203 --> https://bugzilla.suse.com/attachment.cgi?id=842203&action=edit yrepo-sign script snippet - metadata creation and signing we do -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1175119] while doing the autoyast an internal error occurs it says: undefined method `product_package'
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1175119 https://bugzilla.suse.com/show_bug.cgi?id=1175119#c17 Nicolas Nattermann <opensuse-bugs(a)yalwa.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(opensuse-bugs@yal | |wa.com) | --- Comment #17 from Nicolas Nattermann <opensuse-bugs(a)yalwa.com> --- (In reply to Michal Filka from comment #16) > During installation, YaST is searching for available "products" in the > installation source. In your case, Yalwa client was reported as a product > (in particular there were two - differs in arch). However, the repository > with the client doesn't fulfill requirements for "product" repository and > YaST crashes because of that. Thank you for this clear explanation, I now get what overall this is about. > 2) your use case. You want to achieve *something* what I don't know, and it > seems you're doing it wrong at least for the current OpenSUSE release. If > you precisely describe what you want to achieve, I can try to help you or > contact you with someone else who could be able to. What we are doing with this extra yalwa-client repository, is purely internal to our company desktop + laptop installations, have an additional package source for various internally curated packages. These cover various needs we have, partly configuration management, some rather dependency management (drawing in other packages, also from the base openSUSE repos, as rpm dependencies), and some installing internal scripts. very rarely we also override base system packages with newer versions. None of that has to do with any external productization. It's really just our internal way to customize our installs in various ways. We are doing the same (with a separate repository) for our production host + vm installs, and have been doing that since 11.4 times. The basic structure - metadata structure I mean - I did create back then, maybe 9 years ago, from some documentation I found on your web pages, and a bit of guessing from existing repositories. The terminology "product", the line in metadata where we put "Yalwa_Client" then, is just something I found / got that way, not something that is of huge importance to us by itself. For the sake of clarity, I will attach the script we use for the metadata recreation / signing, as we've been doing it for all these years. Thank you for the continued willingness to help us with this! Very appreciated! all the best Patrick Schaaf -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1174593] pam_xauth(.so) module is extremly slow on Leap 15.2
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1174593 https://bugzilla.suse.com/show_bug.cgi?id=1174593#c26 --- Comment #26 from Josef Möllers <josef.moellers(a)suse.com> --- (In reply to Dr. Werner Fink from comment #25) > (In reply to Josef Möllers from comment #24) > > (In reply to Dr. Werner Fink from comment #23) > > > On the other hand ... the pam_xauth already running as root knows about the > > > original user and can execute the reading xauth (with option -i) as user > > > werner > > > > I'm not sure what you mean by "knows about the original user". As far as I > > can see, it does not: PAM_USER is "root", so all traces of the previous user > > are lost. > > At least the pam_unix seems to know > > Oct 02 10:46:02 boole sudo[18052]: pam_unix(sudo-i:session): session opened > for user root by werner(uid=0) This pam_unix gets from pam_get_item(pamh, PAM_USER, (void *) &user_name); pam_xauth does pam_get_user(pamh, &user, NULL) +-->retval = pam_set_item(pamh, PAM_USER, resp->resp); which sets PAM_USER to the new user's name tpwd = pam_modutil_getpwnam(pamh, user); : if (debug) { pam_syslog(pamh, LOG_DEBUG, "requesting user %lu/%lu, target user %lu/%lu", (unsigned long) rpwd->pw_uid, (unsigned long) rpwd->pw_gid, (unsigned long) tpwd->pw_uid, (unsigned long) tpwd->pw_gid); > Oct 02 10:46:02 boole sudo[18052]: pam_xauth(sudo-i:session): requesting > user 0/0, target user 0/0 Hm ... when collecting this stuff, it occurred to me that pam_xauth could retrieve the old user name prior to calling pam_get_user() ... stay tuned ... > Oct 02 10:46:02 boole sudo[18052]: pam_xauth(sudo-i:session): current and > target user are the same, forward X11 > Oct 02 10:46:02 boole sudo[18052]: pam_xauth(sudo-i:session): reading keys > from `/dev/shm/.xauth.j391gjD' > Oct 02 10:46:02 boole sudo[18052]: pam_xauth(sudo-i:session): running > "/usr/bin/xauth -f /dev/shm/.xauth.j391gjD nlist :3" as 0/0 > Oct 02 10:48:00 boole sudo[18052]: pam_xauth(sudo-i:session): no key > > last line does not work as the fifo there is not open with -i -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1174593] pam_xauth(.so) module is extremly slow on Leap 15.2
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1174593 https://bugzilla.suse.com/show_bug.cgi?id=1174593#c24 Josef Möllers <josef.moellers(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags| |needinfo? --- Comment #24 from Josef Möllers <josef.moellers(a)suse.com> --- (In reply to Dr. Werner Fink from comment #23) > On the other hand ... the pam_xauth already running as root knows about the > original user and can execute the reading xauth (with option -i) as user > werner I'm not sure what you mean by "knows about the original user". As far as I can see, it does not: PAM_USER is "root", so all traces of the previous user are lost. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1159882] Excessive swapping when buffers / cache expand beyond free physical RAM
by bugzilla_noreply＠suse.com 02 Oct '20

02 Oct '20

https://bugzilla.suse.com/show_bug.cgi?id=1159882 https://bugzilla.suse.com/show_bug.cgi?id=1159882#c58 --- Comment #58 from Michal Hocko <mhocko(a)suse.com> --- I didn't get to process data yet and will unlikely to do it sooner than next week. I am quite surprised that you still see a swapout though. I assume you have double checked the correct kernel is booted, right? (sorry about the stupid question but with more kernels involved this can happen). Have you tried to test with cgroup_disable=memory as well? -- You are receiving this mail because: You are on the CC list for the bug.

1 0