A random discovery about zypper, thanks to rpm and a deb package
It happens to me to discover some quirks and facts by accident. Today, something that made me question the design of zypper
, a crucial openSUSE tool! Here’s the full story, which is a very short one.
Linux Lite has a very nice System Monitoring Center, which is a fork of Hakan Dündar’s homonymous tool, which has been abandoned, unfortunately:
*** Announcement (31.10.2023): End of support for System Monitoring Center v2.x.x. The project is ended. System Monitoring Center 12.2020-10.2023. ***
Besides that, the two tools look radically different. Here’s the original one (version 2.26.0):
And here’s Jerry Bezencon’s fork for Linux Lite (version 6.8.1):
Jerry’s is better because it can show all the cores (threads, actually) at once. This is the major flaw of the original tool.
What happens is that I tried to build Jerry’s one, but being a Python thing, I didn’t know what to do. There isn’t anything to configure, and no makefile, just a bunch of files that needed to be packaged into a .deb
, which I have no idea how to do. Without a .spec
, I cannot build a .rpm
, and the sources offered by Jerry are not offered in good faith.
To have been offered in good faith means to have the source package, which in Debian isn’t another .deb
(oh, .rpm
is so consistent!), but a trio: (1) a .dsc
file, (2) the original sources as .tar.xz
, and (3) a .debian.tar.xz
that includes the actions to be taken to patch the sources and build the installable .deb
package. In the absence of the last one, I can’t figure out what to do, other than to copy those files in the filesystem. This could have been enough, but I still wanted either to install a package, or to use make
.
Either way, I played with the .deb
file for Linux Lite, thinking that, given that it’s only a bunch of .py
and images, it should be convertible with alien into a .rpm
, which would then be installable. Dependency issues were to be expected due to different package naming in Ubuntu vs RHEL, but I wanted to give it a try.
You won’t guess what errors were thrown by rpm -i
! It said that the .rpm
file obtained through conversion by alien
wanted to override dozens of files that were actually system directories, such as:
/usr/bin
/usr/lib
/usr/share
/usr/share/icons/hicolor/scalable
/usr/share/locale/pt_BR
and so on. Well, to be more accurate, the errors were phrased like this:
file /usr/share from install of system-monitoring-center_6.8.1.noarch conflicts with file from package filesystem-3.16-2.el9.x86_64
Of course, RPM is stupid:
- While everything is a file in Linux, these are folders, and this is an important distinction, especially as it’s not apparent what exactly can conflict with a folder that exists since the OS has been installed, and in which all packages install files!
- The nature of the conflict is unspecified. Most people would think in terms of overwriting a file, which is not the case here.
To find what exactly was about to be overridden or overwritten, one should use rpm -V
. And then, for all the conflicting “files” (folders), the line would start with this:
.M.......
That means (what, isn’t it self-explanatory?) that what’s different between the two versions is related to the Mode, which includes the permissions and the file type.
Further clarifications come from this openSUSE forum thread, in which someone complained that:
rpm
refused to install arpm
, with exactly this type of conflict, butzypper
just went along and installed it, no complaints, no questionx asked.
A nincompoop (see, I can use words other than “retard”!) came with this retarded (ouch!) thing in the context, as he clearly failed to read the exact error message:
zypper does check the whole situation and acts accordingly, it will e.g. install extra packages when they are dependencies, or offer you to choose a solution as in this case.
This is not about rpm
vs zypper
, because Red Hat too has a dependency solver called dnf
(yum
in the past).
Thankfully, the last comment is correct and enlightening:
RPM is correct here.
It has nothing to do with dependencies.
zypper
does equivalent of “rpm --nodeps --force --noscripts
” and evaluates dependencies and conflicts itself. In this case,filesystem
package has/usr/share
with modes 0555 (r-xr-xr-x
) whilemaster-pdf
package has/usr/share
with modes -755 (rwxr-xr-x
). So forcing installation makes this directory writable.RPM allows directories “shared” between packages as long as their attributes are identical. Here attributes are different, so RPM quite correctly refuses to install (without forcing installation). Zypper pretends to know better than RPM but does not implement this check.
That’s 100% right.
I didn’t check the modes in Jerry’s .deb
and how alien has ported them to the .rpm
, nor were those of the system directories. It’s enough that they’re different. Now, I have two takeaways:
■ RPM is right in principle, but it’s stupid in practice. It’s right to refuse to alter the permissions of system folders. It’s stupid because:
- It doesn’t say explicitly: “
folder1 with mode -755 from package1 wants to override mode 0555 from package2
”. WTF, is it so difficult to spit out the reason? - It doesn’t include an option to ignore all the conflicts by doing nothing but going on with the non-conflicting actions, i.e. by skipping the respective files or folders! In this case, as well as the case in that forum, the package wanted to create those folders, but as they already exist, it’s enough to copy inside the actual files. It would have been rocket science for
rpm
to ask: “package1 wants to create or modify existing directories: ignore or abort?
” Of course it would be. We’re in 1997.
■ Zypper is much worse. First, it doesn’t check the modes; it is indeed behaving like “rpm --nodeps --force --noscripts
”. Or, if it’s actually silently ignoring the conflicts despite being aware of them, what is it that it’s doing?
- It ignores the mode change request, which is what
rpm
should do, if not by default, then by using a flag. - It honors the mode change request, thus potentially breaking the security of the system.
We cannot know. The only way to find out is to install such a package with zypper
, and compare the modes of the conflicting folders before and after the installation. But to know that there are such conflicts, one should first use rpm
and fail!
This is completely insane. I just lost my confidence in Zypper and in openSUSE!
Incidentally, the permissions in Linux Lite are correct. I checked the Live ISO, and permissions for /usr/share
are drwxr-xr-x
(0755) in both Linux Lite 7 and AlmaLinux 9.4. So the queer rpm
could be the result of a bad conversion by alien
. Or maybe the .deb
itself has issues, but Linux Lite comes with the package preinstalled, so nobody noticed unless they uninstalled and reinstalled the package. And I’ll never know how would dpkg
and apt
behave in the case of such conflicts… because I don’t feel like investigating.
UPDATE: I just checked what Zypper does, and I actually tried YaST Software, the GUI version. I used the .rpm
converted from .deb
by alien
under AlmaLinux, because the unofficial builds of alien
available for openSUSE Leap failed to work.
I can confirm that zypper
silently accepts overriding the modes (permissions) of system directories without raising any warning, let alone asking the user for confirmation!
Before installing of that package:
After having installed that package:
Now, /usr/bin
, /usr/lib
and /usr/share
have been made writable! OK, they’re now writable by the members of the group (root
), not by others, but this is a matter of principle: the standard permissions for system directories are there for a reason, and changing them without even informing the user is unacceptable!
OpenSUSE, you suck. You’re insecure. Why are people still using you?
Leave a Reply