|
Bugzilla – Full Text Bug Listing |
| Summary: | different behaviour of sudo-1.9.15p5-150600.1.1.x86_64 in SLES15 SP6 RC1-202403 | ||
|---|---|---|---|
| Product: | [openSUSE] PUBLIC SUSE Linux Enterprise Server 15 SP6 | Reporter: | Johann Pickl <Johann.PB.Pickl> |
| Component: | Basesystem | Assignee: | Simon Lees <simonf.lees> |
| Status: | CONFIRMED --- | QA Contact: | |
| Severity: | Normal | ||
| Priority: | P2 - High | CC: | aalzayed, david.anes, Johann.PB.Pickl, meissner, otto.hollmann, simonf.lees |
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Hardware: | Other | ||
| OS: | Other | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
| Bug Depends on: | |||
| Bug Blocks: | 1226008 | ||
Exactly this issue is described here > https://github.com/sudo-project/sudo/issues/333 and it was introduced by patch for > https://github.com/sudo-project/sudo/issues/228 The first issue is still open and upstream is not going to fix it at the moment because it will reintroduce/break fix for second issue. So I think we have to deal with this "new" behaviour. (In reply to Otto Hollmann from comment #1) > Exactly this issue is described here > > https://github.com/sudo-project/sudo/issues/333 > and it was introduced by patch for > > https://github.com/sudo-project/sudo/issues/228 > > The first issue is still open and upstream is not going to fix it at the > moment because it will reintroduce/break fix for second issue. So I think we > have to deal with this "new" behaviour. The "new" behaviour might block a lot of our customer to upgrade to SLES 15 SP6. Is there any chance to get the old behaviour back? I noticed, that on Tumbleweed this issue does not occur. It's weird because we have the same sudo version on Tumbleweed and on SLE15-SP6. Also the spec files are identical. The only difference is location of configuration files (/usr/etc/sudoers vs. /etc/sudoers) but it shouldn't be relevant since "sudo -l" sucessfully reads config files. I'm wondering if this could be caused by something different (kernel?). (In reply to Otto Hollmann from comment #3) > I noticed, that on Tumbleweed this issue does not occur. > > It's weird because we have the same sudo version on Tumbleweed and on > SLE15-SP6. Also the spec files are identical. The only difference is > location of configuration files (/usr/etc/sudoers vs. /etc/sudoers) but it > shouldn't be relevant since "sudo -l" sucessfully reads config files. > > I'm wondering if this could be caused by something different (kernel?). In TW, both /bin/cat and /usr/bin/cat are actual executables (in my machine at least) and that's why it doesn't fail: > ~ ❯❯❯ ls -l /usr/bin/cat /bin/cat > -rwxr-xr-x 1 root root 35088 Apr 1 20:07 /bin/cat* > -rwxr-xr-x 1 root root 35088 Apr 1 20:07 /usr/bin/cat* Compared to what @Johann has reported in SLE SP6: > qqbckup@itadell208:~> ls -l /usr/bin/cat /bin/cat > lrwxrwxrwx 1 root root 12 May 7 2022 /bin/cat -> /usr/bin/cat > -rwxr-xr-x 1 root root 35752 May 7 2022 /usr/bin/cat The question now is... why is that different in SP6 compared to TW? SLES 15 SP6 (Snapshot-202404-1) still use the coreutile from SLES 15 SP4
itavmwhans06:~ # rpm -qf /usr/bin/cat /bin/cat
coreutils-8.32-150400.7.5.x86_64
coreutils-8.32-150400.7.5.x86_64
itavmwhans06:~ # ls -l /usr/bin/cat /bin/cat
lrwxrwxrwx 1 root root 12 May 7 2022 /bin/cat -> /usr/bin/cat
-rwxr-xr-x 1 root root 35752 May 7 2022 /usr/bin/cat
itavmwhans06:~ # zypper se -i --details coreutils
Loading repository data...
Reading installed packages...
S | Name | Type | Version | Arch | Repository
--+-----------+---------+-----------------+--------+---------------------------------
i | coreutils | package | 8.32-150400.7.5 | x86_64 | SLE-Module-Basesystem15-SP6-Pool
itavmwhans06:~ # grep beta /etc/products.d/baseproduct
<betaversion>Snapshot-202404-1</betaversion>
@Johann.PB.Pickl@bmw.de, do you mind to: 1. Share the sudoers config of both SP5 and SP6 (I'm creating vms for testing them right now, but it's still ongoing) 2. If you remove the symlink and cp the executable, does it work? Most probably, it's related to comment #1, but I want to test/check a few things beforehand to discard other issues. I see that in TW there are no symlinks (as you noticed, coreutils was updated since). I'm now trying to find out the specific change to see what we can do there, maybe not providing symlinks but actual executables is an option. Let me ask also coreutils maintainers... Any update? No change of the behaviour with the SLES 15 SP6 GMC and sudo-1.9.15p5-150600.1.2.x86_64 (In reply to Johann Pickl from comment #9) > No change of the behaviour with the SLES 15 SP6 GMC and > sudo-1.9.15p5-150600.1.2.x86_64 Do you mind to check if coreutils was updated meanwhile? Thanks. (In reply to David Anes from comment #10) > (In reply to Johann Pickl from comment #9) > > No change of the behaviour with the SLES 15 SP6 GMC and > > sudo-1.9.15p5-150600.1.2.x86_64 > > Do you mind to check if coreutils was updated meanwhile? Thanks. No, the coretulis rpm was not updated from PublicRC to GMC, it has still version 8.32 Release 150400.9.3.1 build on Mon Feb 12 12:50:36 2024 see also https://beta.suse.com/private/SLE15/SP6/changelogs/PackageChanges-SLE-15-SP6-PublicRC-202404-GMC-202405.txt itavmwhans06:~ # rpm -q coreutils -i Name : coreutils Version : 8.32 Release : 150400.9.3.1 Architecture: x86_64 Install Date: Thu Apr 25 07:43:41 2024 Group : System/Base Size : 6516391 License : GPL-3.0-or-later Signature : RSA/SHA256, Mon Feb 12 12:51:10 2024, Key ID 70af9e8139db7c82 Source RPM : coreutils-8.32-150400.9.3.1.src.rpm Build Date : Mon Feb 12 12:50:36 2024 Build Host : h01-ch3c Relocations : (not relocatable) Packager : https://www.suse.com/ Vendor : SUSE LLC <https://www.suse.com/> URL : https://www.gnu.org/software/coreutils/ Summary : GNU Core Utilities Description : These are the GNU core utilities. This package is the union of the GNU fileutils, sh-utils, and textutils packages. [ arch b2sum base32 base64 basename basenc cat chcon chgrp chmod chown chroot cksum comm cp csplit cut date dd df dir dircolors dirname du echo env expand expr factor false fmt fold groups head hostid id install join link ln logname ls md5sum mkdir mkfifo mknod mktemp mv nice nl nohup nproc numfmt od paste pathchk pinky pr printenv printf ptx pwd readlink realpath rm rmdir runcon seq sha1sum sha224sum sha256sum sha384sum sha512sum shred shuf sleep sort split stat stdbuf stty sum sync tac tail tee test timeout touch tr true truncate tsort tty uname unexpand uniq unlink uptime users vdir wc who whoami yes Distribution: SUSE Linux Enterprise 15 Any update from SUSE? (In reply to Johann Pickl from comment #12) > Any update from SUSE? Not unfortunately, I couldn't spend time to investigate. I misunderstood your previous response as "No change of the behaviour with the SLES 15 SP6 GMC and sudo-1.9.15p5-150600.1.2.x86_64 [from SP5]" instead. We are reassigning this to other engineers to find out if we can locate the root cause, but this may take some time. Meanwhile, if you find any workaround let us know so we can document it, please. We have no workaround. (In reply to Otto Hollmann from comment #1) > Exactly this issue is described here > > https://github.com/sudo-project/sudo/issues/333 > and it was introduced by patch for > > https://github.com/sudo-project/sudo/issues/228 > > The first issue is still open and upstream is not going to fix it at the > moment because it will reintroduce/break fix for second issue. So I think we > have to deal with this "new" behaviour. I think in this case given its SLES and we tend to prioritize not breaking existing behavior the safest option will be to revert that patch for SLE-15-SP6, even though it will come back for SLES 16, but atleast in this case that customers issue will be fixed via the newer coreutils I got a PTF, which works fine https://ptf.suse.com/d5fa8031bfac6dd80e54aa54d9f4a579/sles15-sp6/28169/x86_64/20240607-1/ sudo-1.9.15p5-150600.1.2.28169.2.PTF.1226008.x86_64 (In reply to Johann Pickl from comment #17) > I got a PTF, which works fine > > https://ptf.suse.com/d5fa8031bfac6dd80e54aa54d9f4a579/sles15-sp6/28169/ > x86_64/20240607-1/ > > sudo-1.9.15p5-150600.1.2.28169.2.PTF.1226008.x86_64 Great, we've started the process of getting that version into the Update repo for 15sp6 SUSE-RU-2024:2075-1: An update that has two fixes can now be installed. Category: recommended (moderate) Bug References: 1222104, 1226008 Maintenance Incident: [SUSE:Maintenance:34276](https://smelt.suse.de/incident/34276/) Sources used: openSUSE Leap 15.6 (src): sudo-1.9.15p5-150600.3.3.2 Basesystem Module 15-SP6 (src): sudo-1.9.15p5-150600.3.3.2 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. |
The following sudo commando works with SLES 15 SP5 (sudo-1.9.12p1-150500.5.1.x86_64) qqbckup@itadell200:~> rpm -q sudo sudo-1.9.12p1-150500.5.1.x86_64 qqbckup@itadell200:~> sudo -l Matching Defaults entries for qqbckup on itadell200: always_set_home, !insults, !umask, !fqdn User qqbckup may run the following commands on itadell200: (root) NOPASSWD: /bin/cat /var/log/messages qqbckup@itadell200:~> ls -l /usr/bin/cat /bin/cat lrwxrwxrwx 1 root root 12 May 7 2022 /bin/cat -> /usr/bin/cat -rwxr-xr-x 1 root root 35752 May 7 2022 /usr/bin/cat qqbckup@itadell200:~> which cat /usr/bin/cat qqbckup@itadell200:~> sudo cat /var/log/messages ... 2024-03-28T08:01:44.231513+01:00 itadell200 sshd[8912]: Close session: user qqnagio from 10.30.16.159 port 46092 id 0 qqbckup@itadell200:~> sudo /usr/bin/cat /var/log/messages .. 2024-03-28T08:04:04.964374+01:00 itadell200 systemd[1]: Configuration file /usr/lib/systemd/system/collectl.service is marked world-inaccessible. This has no effect as configuration data is. ############################################################################## On SLES 15 SP6 RC1-202403 with sudo-1.9.15p5-150600.1.1.x86_64 the old sudo commdos do not work (user qqbckup will be asked for a password) qqbckup@itadell208:~> rpm -q sudo sudo-1.9.15p5-150600.1.1.x86_64 qqbckup@itadell208:~> sudo -l Matching Defaults entries for qqbckup on itadell208: always_set_home, !insults, !umask, !fqdn User qqbckup may run the following commands on itadell208: (root) NOPASSWD: /bin/cat /var/log/messages qqbckup@itadell208:~> ls -l /usr/bin/cat /bin/cat lrwxrwxrwx 1 root root 12 May 7 2022 /bin/cat -> /usr/bin/cat -rwxr-xr-x 1 root root 35752 May 7 2022 /usr/bin/cat qqbckup@itadell208:~> which cat /usr/bin/cat qqbckup@itadell208:~> sudo cat /var/log/messages We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. For security reasons, the password you type will not be visible. [sudo] password for qqbckup: qqbckup@itadell208:~> sudo /usr/bin/cat /var/log/messages We trust you have received the usual lecture from the local System Administrator. It usually boils down to these three things: #1) Respect the privacy of others. #2) Think before you type. #3) With great power comes great responsibility. For security reasons, the password you type will not be visible. [sudo] password for qqbckup: qqbckup@itadell208:~> sudo /bin/cat /var/log/messages ... 2024-03-28T08:13:55.241281+01:00 itadell208 sshd[16003]: Close session: user qqnagio from 10.30.16.159 port 40880 id 1 ############################################################################# Summary: In both cases "/bin/cat /var/log/messages" is included in /etc/sudoers for user qqbckup. * For SLES 15 SP5 (sudo-1.9.12p1-150500.5.1.x86_64) the commands "sudo /usr/bin/cat /var/log/messages" and "sudo cat /var/log/messages" work for the user qqbckup * For SLES 15 SP6 RC1-202403 (sudo-1.9.15p5-150600.1.1.x86_64) the commands "sudo /usr/bin/cat /var/log/messages" and "sudo cat /var/log/messages" don not work for the user qqbckup - the user qqbckup will be asked for a password. Only the command "sudo /bin/cat /var/log/messages" with the correct path works