November 2022 - openSUSE Bugs - openSUSE Mailing Lists

[Bug 1204860] [SELinux] Installed selinux (after fresh install): no labeling, got locked out
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204860 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Installed selinux (after |[SELinux] Installed selinux |fresh install): no |(after fresh install): no |labeling, got locked out |labeling, got locked out -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1205094] Base:System/sudo: user is not in the sudoers file - after Update
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1205094 https://bugzilla.suse.com/show_bug.cgi?id=1205094#c16 Dominique Leuenberger <dimstar(a)opensuse.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dimstar(a)opensuse.org --- Comment #16 from Dominique Leuenberger <dimstar(a)opensuse.org> --- I have reverted sudo back to the rev from before this change was introduced (and branched it into the Update channel to get a quicker update out to users) https://build.opensuse.org/package/revisions/openSUSE:Factory/sudo (CVE patch that came in later was re-applied) As for openQA: openQA DOES test sudo - but it seems it does not test the default config at all. The test actually adds explicit config entries for users (with and without password checks, via user name and via group membership) -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204605] [Build 20221022] SELinux: openQA test fails in tdup
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204605 https://bugzilla.suse.com/show_bug.cgi?id=1204605#c18 --- Comment #18 from Johannes Segitz <jsegitz(a)suse.com> --- Thanks for checking. I would argue that if an attacker is able to influence the environment of this root process than it's game over already. Also it only changes behavior in the error case, when the new policy has changes that are incompatible with the old one. So even if someone would be able to do this the impact is very very limited. Also as you stated this is an already existing mechanism, so I would like to reuse it if possible. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204860] Installed selinux (after fresh install): no labeling, got locked out
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204860 https://bugzilla.suse.com/show_bug.cgi?id=1204860#c1 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|security-team(a)suse.de |jsegitz(a)suse.com --- Comment #1 from Johannes Segitz <jsegitz(a)suse.com> --- Thanks for the report. 1199520 is specific to transactional systems, so it's likely something different. To me it sounds like you installed SELinux manually, but I can't quite follow it (e.g. selinux-targeted-setup doesn't exist). Please give this a try: zypper in selinux-policy-targeted restorecond selinux-policy-devel policycoreutils setools-console policycoreutils-devel policycoreutils-python-utils sed -i -e 's/SELINUXTYPE=minimum/SELINUXTYPE=targeted/' /etc/selinux/config sed -i -e 's/SELINUX=disabled/SELINUX=permissive/' /etc/selinux/config if ! egrep 'GRUB_CMDLINE_LINUX_DEFAULT.*security=selinux selinux=1' /etc/default/grub >/dev/null; then sed -i -E 's/(GRUB_CMDLINE_LINUX_DEFAULT=.*)"/\1 security=selinux selinux=1"/' /etc/default/grub fi update-bootloader --refresh reboot the system and check if it looks properly labeled. If it does you can change it to enforcing with: sed -i -e 's/SELINUX=permissive/SELINUX=enforcing/' /etc/selinux/config and reboot -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204928] AUDIT-0: openSUSE Leap Micro 5.3 RC/GM security audit
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204928 https://bugzilla.suse.com/show_bug.cgi?id=1204928#c2 Johannes Segitz <jsegitz(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|security-team(a)suse.de |jsegitz(a)suse.com --- Comment #2 from Johannes Segitz <jsegitz(a)suse.com> --- I agree, we don't need a full audit here, but I'll have a quick look this week -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1204956] New: Cached repo packages are deleted
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1204956 Bug ID: 1204956 Summary: Cached repo packages are deleted Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.4 Hardware: Other OS: openSUSE Leap 15.4 Status: NEW Severity: Normal Priority: P5 - None Component: libzypp Assignee: zypp-maintainers(a)suse.de Reporter: bugz57(a)top.geek.nz QA Contact: qa-bugs(a)suse.de Found By: --- Blocker: --- OpenSUSE doesn't have a mechanism for caching repo content locally for sharing between hosts, mirrors around here can be slow and bad, plus I see it as bad style to waste server bandwidth. So the next best thing is sharing /var/cache/zypp/packages/. That works only if the configured repos on all hosts are identical. Any host which does not have a repo configured proceeds to simply delete all cached content of that repo. Please - not having a downloaded-rpms-cache is pretty bad in my opinion, but going out of the way to delete already downloaded data is not acceptable. It is my understanding that the package updates are controlled by the repo metadata anyway that is downloaded when refreshing repos, and there should be no need to delete any already downloaded rpm. Old hardware these days is likely RAM bound, but not disk-space bound, and anyone really having space problems can manually delete /var/cache/zypp/packages/ without detriment to future package updates. Can zypper please refrain from deleting any already downloaded rpms/drpms? -- You are receiving this mail because: You are on the CC list for the bug.

1 11

[Bug 1204790] gcc12: don't require glibc-devel-32bit if %disable_32bit
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1204790 https://bugzilla.suse.com/show_bug.cgi?id=1204790#c4 --- Comment #4 from Ludwig Nussel <lnussel(a)suse.com> --- (In reply to Richard Biener from comment #3) > (In reply to Ludwig Nussel from comment #2) > > omg, yes I think we should get rid of that hack. > > > > glibc-devel-32bit already requires glibc-32bit so I think the first > > substitute is line is not needed at all. > > > > So can we introduce eg %with_biarch or something like that and have the > > basic logic in the gcc spec file itself? > > Sure, but then the glibc-32bit "hack" is/was used from other packages as > well. Didn't encounter any others in ring0 at least. > Somebody needs to document the canonical way to query enabled multilibs from > the project config (and make that materialize in all supported code streams!) So far I only found gcc that cares about multilib. Most other packages just don't know about the baselibs mechanism. Do you know of any other package that needs to behave differently when there is biarch support? Anyway glibc in SLE12 also has correct requires according SUSE:SLE-12-SP4:Update/glibc/baselibs.conf So the hack isn't needed there either. -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1200324] New: Build service creates broken meta files in repositories
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

http://bugzilla.opensuse.org/show_bug.cgi?id=1200324 Bug ID: 1200324 Summary: Build service creates broken meta files in repositories Classification: openSUSE Product: openSUSE.org Version: unspecified Hardware: Other OS: Other Status: NEW Severity: Normal Priority: P5 - None Component: BuildService Assignee: screening-team-bugs(a)suse.de Reporter: sndirsch(a)suse.com QA Contact: adrian.schroeter(a)suse.com Found By: --- Blocker: --- Just noticed that the Build Service apparently creates broken meta files in repositories. https://build.opensuse.org/project/show/X11:Drivers:Video # sudo zypper addrepo https://download.opensuse.org/repositories/X11:/Drivers:/Video/SLE_15_SP4/ X11:Drivers:Video2 Adding repository 'X11:Drivers:Video2' ...................................[done] Repository 'X11:Drivers:Video2' successfully added URI : https://download.opensuse.org/repositories/X11:/Drivers:/Video/SLE_15_SP4/ Enabled : Yes GPG Check : Yes Autorefresh : No Priority : 99 (default priority) Repository priorities in effect: (See 'zypper lr -P' for details) 80 (raised priority) : 2 repositories 90 (raised priority) : 2 repositories 99 (default priority) : 12 repositories 100 (lowered priority) : 9 repositories # sudo zypper ref X11:Drivers:Video [...] New repository or package signing key received: Repository: X11:Drivers:Video Key Fingerprint: C574 FD10 5C13 81E5 53E5 A73E 5904 01A1 E38F B563 Key Name: X11:Drivers:Video OBS Project <X11:Drivers:Video@build.opensuse.org> Key Algorithm: RSA 2048 Key Created: Fri 13 May 2022 05:21:38 PM UTC Key Expires: Sun 21 Jul 2024 05:21:38 PM UTC Rpm Name: gpg-pubkey-e38fb563-627e93a2 Note: Signing data enables the recipient to verify that no modifications occurred after the data were signed. Accepting data with no, wrong or unknown signature can lead to a corrupted system and in extreme cases even to a system compromise. Note: A GPG pubkey is clearly identified by it's fingerprint. Do not rely the keys name. If you are not sure whether the presented key is authentic, ask the repository provider or check his web site. Many provider maintain a web page showing the fingerprints of the GPG keys they are using. Do you want to reject the key, trust temporarily, or trust always? [r/t/a/?] (r): t Retrieving repository 'X11:Drivers:Video' metadata ..............................................................................................................[error] Repository 'X11:Drivers:Video' is invalid. [X11:Drivers:Video|https://download.opensuse.org/repositories/X11:/Drivers:/…] Valid metadata not found at specified URL History: - File './repodata/3cfe905631eef842d7d8a2e7f64a687db42f7aa2bc15807330ed76e0badb38e2-primary.xml.gz' not found on medium 'https://download.opensuse.org/repositories/X11:/Drivers:/Video/SLE_15_SP4/' - Can't provide ./repodata/3cfe905631eef842d7d8a2e7f64a687db42f7aa2bc15807330ed76e0badb38e2-primary.xml.gz Please check if the URIs defined for this repository are pointing to a valid repository. Skipping repository 'X11:Drivers:Video' because of the above error. Some of the repositories have not been refreshed because of an error. -- You are receiving this mail because: You are on the CC list for the bug.

1 2

[Bug 1197778] Logon screen taking too long to display logon screen
by bugzilla_noreply＠suse.com 07 Nov '22

07 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1197778 Chenzi Cao <chcao(a)suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |qzhao(a)suse.com Assignee|chcao(a)suse.com |snwint(a)suse.com -- You are receiving this mail because: You are on the CC list for the bug.

1 0

[Bug 1202241] corner case: package update does not work via SUSE Manager
by bugzilla_noreply＠suse.com 06 Nov '22

06 Nov '22

https://bugzilla.suse.com/show_bug.cgi?id=1202241 https://bugzilla.suse.com/show_bug.cgi?id=1202241#c12 --- Comment #12 from Angelika Torl�e <atorlee(a)suse.com> --- Thank you for the analysis and for the fix. The packages in question are from the customer development team. I will forward the info on your spec file updates to those developers. Thank you all for your support! -- You are receiving this mail because: You are on the CC list for the bug.

1 0