Page 79
Page 80
Table 6.1. Verify-mode command syntax and options.
| rpm -V (or --verify, or -y) | Options | |
| Package Selection Options | Section | |
| pkg1...pkgN | Verify named package(s) | 6.3.1 |
| -p <file> | Verify against package file <file> | 6.3.4 |
| -f <file> | Verify package owning <file> | 6.3.3 |
| -a | Verify all installed packages | 6.3.2 |
| -g <group> | Verify packages belonging to group <group> | 6.3.5 |
| Verify-Specific Options | Section | |
| --noscripts | Do not execute verification script | 6.3.7 |
| --nodeps | Do not verify dependencies | 6.3.6 |
| --nofiles | Do not verify file attributes | 6.3.8 |
| General Options | Section | -v |
| Display additional information | 6.3.9 | -vv |
| Display debugging information | 6.3.10 | --root <path> |
| Set alternate root to <path> | 6.3.12 | --rcfile <rcfile> |
| Set alternate rpmrc file to <rcfile> | 6.3.13 | --dbpath <path> |
| Use <path> to find the RPM database | 6.3.11 |
From time to time, it's necessary to make sure that everything on your system is okay. Are you sure the packages you've installed are still configured properly? Have there been any changes made that you don't know about? Did you mistakenly start a recursive delete in /usr and now you have to assess the damage?
RPM can help. It can alert you to changes made to any of the files installed by RPM. Also, if a package requires capabilities provided by another package, it can make sure the other package is installed, too.
The command rpm -V (or -y, or --verify, which are equivalent) verifies an installed package. Before we see how this is done, let's take a step back and look at the big picture.
Every time a package is installed, upgraded, or erased, the changes are logged in RPM's database. It's necessary for RPM to keep track of this information; otherwise, it wouldn't be able to perform these operations correctly. You can think of the RPM database (and the disk space it
Page 81
consumes) as being the price of admission for the easy package management that RPM provides. (Actually, the price is fairly low. For a completely RPM-based Linux distribution, it would be unusual to have a database over 5MB.)
The RPM database reflects the configuration of the system on which it resides. When RPM accesses the database to see how files should be manipulated during an install, upgrade, or erase, it is using the database as a mirror of the system's configuration.
However, we can also use the system configuration as a mirror of the RPM database. What does this backward view give us? What purpose would be served?
The purpose would be to see if the system configuration accurately reflects the contents of the RPM database. If the system configuration doesn't match the database, we can reach one of two conclusions:
While RPM databases occasionally are corrupted, it is a sufficiently rare occurrence that the second conclusion is much more likely. So RPM gives us a powerful verification tool, essentially for free.
It would be handy if RPM did nothing more than verify that every file installed by a package actually exists on your system. In reality, RPM does much more. It makes sure that if a package depends on other packages to provide certain capabilities, the necessary packages are, in fact, installed. If the package builder created one, RPM will also run a special verification script that can verify aspects of the package's installation that RPM cannot.
Finally, every file installed by RPM is examined. No fewer than the following nine attributes of each file can be checked:
Let's take a look at each of these attributes and why they are good things to check.
Page 82
Most operating systems today keep track of each file's creator. This is done primarily for resource accounting. Linux and UNIX also use file ownership to help determine access rights to the file. In addition, some files, when executed by a user, can temporarily change the user's ID, normally to a more privileged ID. Therefore, any change of file ownership may have far-reaching effects on data security and system availability.
In a similar manner to file ownership, a group specification is attached to each file. Primarily used for determining access rights, a file's group specification can also become a user's group ID, should that user execute the file's contents. Therefore, any changes in a file's group specification are important and should be monitored.
Encompassing the file's permissions, the mode is a set of bits that specifies permitted access for the file's owner, group members, and everyone else. Even more important are two additional bits that determine whether a user's group or user ID should be changed if he executes the program contained in the file. Since these little bombshells can let any user become root for the duration of the program, it pays to be extra careful with a file's permissions.
The MD5 checksum of a file is simply a 128-bit number that is mathematically derived from the contents of the file. The MD5 algorithm was designed by Ron Rivest, the R in the popular RSA public-key encryption algorithm. The MD in MD5 stands for message digest, which is a pretty accurate description of what it does.
Unlike literary digests, an MD5 checksum conveys no information about the contents of the original file. However, it possesses one unique trait: Any change to the file, no matter how small, results in a change to the MD5 checksum. (From a strictly theoretical standpoint, this is not entirely true. Using the lingo of cryptologists, it is believed to be "computationally infeasible" to find two messages that produce the same MD5 checksum.)
RPM creates MD5 checksums of all files it manipulates, and stores them in its database. For all intents and purposes, if one of these files is changed, the MD5 checksum will change, and RPM will detect it.
As if the use of MD5 isn't enough, RPM also keeps track of file sizes. A difference of even 1 byte more or less will not go unnoticed.