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.
rpmio/digest.h contains definitions that are only used by the interal
OpenPGP parser, and are not required by the future Sequoia backend.
Move those definitions into rpmio/rpmpgp_internal.h.
Fixes#2006.
- Add accessor functions pgpDigParamsSignID, pgpDigParamsUserID,
pgpDigParamsVersion, and pgpDigParamsTime.
- Move the definition of `pgpDigParams_s` from `rpmio/digest.h` to
`rpmio/rpmpgp.c`.
- Change code to use the accessor functions.
- Fixes#1979.
The fs keyring doesn't of course need the header to be created, but
going through the same motions ensures consistent results, ie the
key goes throught the same validation steps and we also get a
"descriptive" file name for free (descriptive in that it matches the
rpmdb NVR)
The keyring a transaction uses shouldn't change by somebody defining
macro in the meanwhile. Add an enum for known types and a helper to
lazily determine it on the first keyring load.
Commit 2d52726bd5 was not SUPPOSED to
change any behavior, but it did: "shared" colored files (ie one being
wrong color and the other one actually installed) removed in the
same transaction would not get removed at all. Fix the embarrasment
that happens when you don't have systematic tests.
Fixes: #1800
Commit f311fb65ee added a step to reset
calculated states between rpmtsRun() calls to allow for %pretrans
hacks, but this causes actions set for --excludepath to get lost.
While those do get recalculated at the time of actual install and
correctly skipped, this causes them to be considered for file
disposition which they should not.
Files that are not installed cannot conflict with anything, any more
than skipped files can. The latter we handled, the former not. Strange
what "obvious" cases can go on unnoticed forever, when lacking systematic
tests.
fsmClose() does all the necessary checks and resets the fd to -1 after
close, why duplicate these all over the code when we already have a
function...
There's no difference wrt file descriptors getting closed here, but
there is a side-effect to this: if %_flush_io is enabled, they now
get fsync() on the associated directories too, which I think is a good
thing for those who care about it.
Commit 0e3024ca3e introduced a leak on
directory file descriptors from hardlinked sets, preventing some large
packages with many hardlinks from installing at all.
fsmMkfile() needs to close the firstdir fd when done with it because
that's the only place that knows when it's safe to do so. However, there
could be non-hardlink entries left in the same directory, so we must not
close *that* descriptor. Dup the firstdir descriptor so we're free to
close it without worrying about the other state.
Fixes: #1947
This is insecure in so many ways I'm not going to bother trying to list
them all. It's an undocumented "feature" left over from more innocent
times, time to give it the axe.
Introduced back in 2007 in 5831404601 the
point was to fake up a sane public header structure with minimal
internal disruption, TEMPORARILY. I think 15 years is temporary enough.
The machinery has worked rather well for what it is, but having the
headers appear in multiple locations is weird and confusing to people,
plus this "physical" separation makes it far more clearer what is
a public header and what isn't.
Stop including rpmtag.h from rpmtypes.h, fix callers instead.
This fixes the long-standing issue that rpmtypes.h is not the
free-standing header it's supposed to be and that its sole purpose
is, ie safe to include from anywhere.
This is continuation to the previous commit, this was necessary for
clean Berkeley DB shutdown but current backends do not need it. And
as we no longer route signals through a polled machinery to get an
exit() from eg ctrl-c, this is for all practical purposes dead code,
callers are expected to free their iterators as needed anyway.
As a bonus, eliminating these static structures improves thread-safety
without complicated locking.
The rpm signal queue (rpmsq) was necessary to support clean shutdown
of Berkeley Database on signals, but our current backends do not
need such handholding. A library silently hogging your signals on
function call is antisocial behavior, stop doing that since we no
longer have to.
Since the rpmsq is no longer active in transactions, use sigaction()
instead of rpmsqSetAction() to manipulate SIGPIPE. While at it,
eliminate the use of deprecated signal() which in particular should
not be mixed with sigaction() use.
This is quite a dramatic behavior change to a long-standing behavior
so while everybody hated the signal hogging, this may still cause some
fallout in strange places.
This also makes a whole lot of rpmsq code redundant and unused, leaving
it in place for the time being as a backup if we need to revert
short term, to be flushed in the next soname bump.
Commit cb6aa82dbc unblocked all signals
from scriptlets, but turns out this is too much: SIGINT, SIGTSTP and
SIGQUIT sent from the terminal are passed to the process group, and
with unblocked signals end up killing our scriptlets while rpm itself
continues. -ENOSENSE.
Stopping (and continuing) is okay though so we don't block that.
RPMTAG_ARCHSUFFIX from commit e6a6399cb4
assumes all headers have RPMTAG_ARCH, but a notable exception is gpg-pubkey
headers in rpmdb, causing segfaults on `rpm -qa` on normal systems.
Special case conditionals in queryformats get ugly and error-prone real
fast, which is why we have all the NEVRA formatter extensions. Avoid
adding yet more of those tags by handling the dot formatting in
ARCHSUFFIX instead - the "suffix" in the name seems to imply this
anyway.
Also add tests to cover the common -qa cases.
At this point this is quite literally merely a symbolic change,
as values from PGP hash algo are assumed equal to RPM hash algos,
but it's a necessary first step to supporting hashes not included
in RFC-4880.
Fixes: #1899
Within fsm this is just a matter of adjusting error messages to include
the directory... if it only wasn't for the plugins requiring absolute
paths for outside users. For the plugins, we need to assemble absolute
paths as needed, both in ensureDir() and plugin file slots.
Cross-directory hardlinks shouldn't be used as there's no guarantee
two directories are on the same filesystem, but these exist in the
wild so we need to care.
Sadly the thing that allegedly makes things better mostly just makes
things more complicated as symlinks can't be opened, so we'll now have
to deal with both cases in plugins too. To make matters worse, most
APIs out there support either an fd or a path, but very few support
the *at() style dirfd + basename approach so plugins are stuck with
absolute paths for now.
This is of course a plugin API/ABI change too.
This being one of the more central functions in fsm now, there better
be some diagnostics from it too. Especially when we move to
dirfd+basename operation.
A thinko originating from commit c9b2686a4748c227b0abdc0752d844e35296474e
which doesn't matter greatly as long as we're still using absolute
paths but will fail as soon as dirfd+basename is used.
Also pay more attention to the rc's: we must not backup, or run file
pre plugin hook if we know it'll fail.
Regular file ops are fd-based already, for the rest we need to open them
manually. Files with temporary suffix must never be followed, for
directories (and pre-existing FA_TOUCHed files) use the rpm symlink
"root or target owner allowed" rule wrt following.
This mostly fixes CVE-2021-35938, but as we're not yet using dirfd-based
operatiosn for everything there are corner cases left undone. And then
there's the plugin API which needs updating for all this.
Panu Matilainen