This is basically a leftover from the initial conversion to the *at()
family in commit 1bab34c6e4 - the logic
was already there and only converted to the *at() form. But this is not
only potentially insecure (remember all those symlink CVEs) but also
wrong simply because it's inconsistent with the other metadata ops which
never follow links in path-based mode.
While it's possible to open special files, they are, well, special and
have "side-effects" also known as, ahem, semantics. Opening a device
file in Unix means accessing that *device*, and FIFOs have their own
semantics. In other words, for rpm's purposes, we should never EVER
open these files as a part of the install / permission setting etc.
Fix this major brainfart in 25a435e908.
OTOH this forces us back to the less secure path based operations for
these files, which is what we were trying to avoid in the first place.
There always was a tiny race between create + open for these (because
there's no atomic way to create + open anything but regular files) but
this opens up the window quite a bit.
Nobody should be placing device nodes in user-owned directories but
FIFO's may be a different story.
We haven't had tests for device nodes because it requires privileges the
test-suite usually doesn't have, not testing FIFOs I have no excuse for.
Add that test now.
Fixes: #2195, #2275
The x86_64 SysV psABI defines four levels of x86_64 with certain CPU
features required for each level. Those definitions are meant to be
generically useful and recognized as such by glibc and gcc as well.
For backward-compatibility and to avoid surprises, default to building
x86_64 even on v2+ capable machines.
The "*eiu->fnp" from "eiu->pkgURL[eiu->pkgx]" which is alloced. when
Fopen or rpmReadPackageFile fails in tryReadHeader, "*eiu->fnp" is
set to NULL but not freed. In addition, if "eiu->pkgState[eiu->pkgx]"
is set, the file is leaked too. Fix it.
Only resource free is added, no other logic change.
The foo_SOURCES style isn't really in cmake ethos, and is wholly
unnecessary here: target_sources() achieves the same exact thing in a
slightly more straightforward way.
These imported targets passed to target_link_library() are supposed to
handle all the pesky compilation, linkage etc details behind the scenes.
I was pretty sure I was missing a trick with this, but this sure isn't
exactly underlined in the documentation.
Unroll the supposedly helpful loop for handling plugins: turns out doing
this cmake native way is plenty shorter and more obvious too. The unroll
kinda belongs to a separate commit but that'd be rather painful for very
little if any gain.
Fixes: #2269 and a whole class of similar cases, allegedly
When installing source rpms, "ei" is malloced and is saved in
blob->ei by rpmReadPackageFile->rpmpkgRead->hdrblobRead, and then
blob->ei is saved in h->blob by rpmReadPackageFile->hdrblobImport,
which is leaked during installation.
We should really do this for all our dependencies, but notably Debian
and derivates have multiple versions of Lua available, each in different
includedir, and build fails without this.
Fixes: #2258
There are some missing bits and pieces still to be done for cmake build,
but that is so much easier if you don't have to worry about keeping
compatibility with the system you're about to remove that it doesn't
make sense to drag this on any further. The sooner this is over, the
sooner it is over and we can start making use of cmake's advantages
instead of just trying to bend over backwards to maintain compatibility
with the autotools build.
A missing epoch is returned as NULL from rpmteE(), but the rpmdb
matching code can't handle NULL in any meaningful way currently.
Arguably it should, but that's a bigger topic...
Specifically convert a missing epoch to a "0" which matches the behavior
in mireSkip() to handle, adjust testcases as appropriate.
These are obviously the long lost uninstall-time counterparts of
%pretrans and %posttrans.
%preuntrans is easy but %postuntrans is the reason this hasn't been
implemented so far: by the time it's supposed to execute, the header will
be gone. Work around this by allowing the rpmte to hold on to its header
if it has a %postuntrans scriptlet.
Cheapskate on transaction flags and reuse pre/posttrans flags for these
uninstall counterparts too, adding separate flags and disablers just
doesn't seem worth it, especially as we're quite short of free bits.
Fixes: #2119
When a glob yields no matches, try accessing a file named like the
literal pattern before finally giving up. Do this for any globs
supplied by the user, be it on the CLI or through a %files section.
We already do this with regular files in %files, this commit just
extends the same logic to the remaining places, namely special files
(%doc or %license) and package files passed on the CLI in install or
query mode (either directly or indirectly through a manifest).
This makes globbing in RPM consistent and more shell-like as Bash does
the same by default.
Do this by treating globs as filenames that may or may not expand into
multiple ones. That way, both cases can be handled by the same code
path.
We don't need to check for the existence of the literal pattern since
that's eventually taken care of in the rpmGlob() caller, such as in
addFile(). As a nice side effect, error reporting for missing glob and
non-glob filenames is now also unified, see the updated tests.
Preserve the public signature of rpmGlob(), though, by adding a new,
more general wrapper that also takes flags. The name is chosen to fit
the pre-existing scheme of rpm*Path() functions in rpmfileutil.h.
Packages need to be able to differentiate between install and upgrade
scenarios, seems commit ab069ec876 with
half the lights out...
As %posttrans happens after all the excitement, with the erasure elements
already executed, so the installed package count cannot be used to
differentiate between install and upgrade. So we need to find it out the
hard way: see if there's an erasure element that depends on this
package.
For the very unlikely case when openat() succeeded but fstatat()
doesn't, the directory descriptor may be leaved opened. Rearrange
the code a bit to ensure it'll always get closed when appropriate.
Suggested-by: Pavel Kopylov <pkopylov@cloudlinux.com>
Suggested-by: Dmitry Antipov <dantipov@cloudlinux.com>
Hack to allow suppressing key import lint warning messages. Emitting
warning messages depending on verbosity level is ugly but for the case
at hand (different output between PGP backends on CI) it's probably the
lesser evil here.
Initial patch by Neal H. Walfield.
Instead of constructing a new list from scratch and returning that, just
extend the passed list. This makes it easier to use this function
incrementally when expanding multiple patterns in a loop, such as during
package manifest parsing which we adapt here right away.
Preserve the ability to pass NULL as argvPtr and still get a match count
via argcPtr, by keeping the local argv around for that case.
No functional change.
This is an incomplete release-early version, NOT intended or
suitable for production use. It is intended to replace the autotools
based buildsystem in rpm 4.20, until then it'll be developed alongside
it. This causes some extra complications of course, but then we avoid
a huge flag-day, and that matters more.
To those wondering why cmake and not ${myfavorite}: the community around
us effectively made that choice for us. We've made a lot of noise about
bootstrap dependencies. When libsolv, dnf and all the related stack is
powered by cmake build, it'd be just foolish to go with anything else.
This way people working on the rpm stack have only one build system to
learn, there's peer support available nearby and bootstrap dependencies
are reduced, not increased. It also doesn't hurt that cmake is actually
and actively maintained.
We currently accept a space-separated list of patterns here so any
backslash, whether it belongs to a space char or not, gets consumed by
poptParseArgvString() before the string is passed to glob(3), requiring
callers to double-escape anything they wish to keep literal.
Fix that by only accepting one pattern. Adapt the one caller which
relies on this actually being a list, in rpmReadPackageManifest(), and
those callers where we preserve spaces by escaping them which is no
longer needed.
Replace our own heuristic emulating GLOB_NOMAGIC with the actual flag to
glob(3) so that literal (double) backslashes are also handled properly.
Keep the indentation of the original for loop to make the diff easier to
read, next commit will fix that.
No immediate effect within RPM since we currently avoid passing escaped
patterns to rpmGlob(), this is just a prerequisite for the following
commits. External users of rpmGlob(), as unlikely as they are, might,
in theory, notice this subtle change but we'll be bumping the soname in
4.19 so that's covered.
cap_compare() is in libcap since 2008 or so, we really don't need to
bother with versions older than that. Another redundant configure check
and a piece of moldy code bites the dust.
Commit d703160334 introduced a new step
to key import which can fail before keyring is initialized.
Always initialize your variables, never need "fixes" like this.
Sqlite WAL threshold of 1000 pages is way too low for rpmdb as a single
header often exceeds that, but disabling the checkpointing entirely can
cause the WAL to grow to multiple gigabytes during large distro update
transactions, which isn't healty either. Bump the threshold to 10000
pages which caps the WAL size to tens of megabytes, which hopefully
is a reasonable balance between performance on rotational disks (anybody
remember those?) and diskpace consumption.
Also drop no longer meaningful link to %_flush_io configuration.
When importing an OpenPGP certificate, lint the certificate to show
the user possible issues. Fail if the certificate is completely
unusable. Using the Sequoia backend, this yields, for instance:
$ ./rpmkeys --import tests/data/keys/alice-revoked-subkey.asc
Certificate B3A771BFEB04E625:
Subkey 1F71177215217EE0 was revoked: Key material has been compromised, it was the maid
Certificate does not have any usable signing keys
Fixes#1974.
The subsequent code relied on buffer lenght being explicit PATH_MAX
which certainly was no longer the case. Clearly, our test-suite does
not excercise this code...
Should've been in commit b1bc46e56a
Since we're requiring POSIX.1-2008 now, we can rely on realpath()
being sane as well. Turns out we've been relying on that in the
debuginfo build-id code since 2016 already (commit
bbfe1f86b2), oops. But then, nobody
has complained...
No functional changes.
Panu Matilainen