Guard the whole mbAppendStr function with ifdef WITH_LUA to avoid a
warning when lua support isn't enabled because it is only used inside
the doLua function (which is empty unles WITH_LUA is defined).
Signed-off-by: Mark Wielaard <mark@klomp.org>
The rpm "major mode" could legitimately be "unknown" here for several
reasons like --eval and usage message is inappropriate in that case
regardless of verbosity setting.
As a side-effect of commit fffd652c56,
only the main Packages db would get created on rebuild if the rebuild
is done on an empty database. Open all indexes before the rebuild
to ensure all indexes get created no matter what.
Spotted by perl-RPM4's test-suite, add the same test to our suite too.
Since commit 3ccd9ccf50, hdrp has only
been set on success (at least half-intentionally), but turns out a
various third party software depends on the former behavior. And on
closer inspection, it's actually a documented feature of the API.
These are not transaction members in the traditional sense as they
simply represent a package that is in the rpmdb and cannot actually
be members of a transaction set (at least not currently). But packages
from the rpmdb can and do participate in the transaction in the form of
triggers and file triggers, and abusing TR_REMOVED for the purpose is
just that - abuse.
This is not supposed to actually change any behavior though.
rpmteDBOffset() simply returns zero for non-installed packages, which
is actually useful for determining whether a TR_ADDED package has
already been installed or not, rpm even relies on this. Remove a couple
of other questionable TR_REMOVED comments too.
For consistency with rpmReadPackageFile() (which changed behavior
similarly in the grand package read unification) and common practise,
only set return values pointers when we have something to return.
Other than that, everybody gets to initialize their own variables.
Also don't dereference msg, we really dont need to know whether it
points to a NULL string ornot in order to set it.
Symlink sizes inside fakechroot environment used to be incorrect
in some situations, quite naturally since those links *are* longer
on disk. This was fixed a long long time ago in fakechroot 2.10 but
Fedora was stuck with 2.9 for a long time so... Anyway, good riddance.
No need for the separate accessor calls now, just use the data from
the stat struct from rpmfilesStat(). No functional changes, but this
depends on commit b7f6ad3919 to get the
size right.
Casts from the past are not needed when we use mode_t for dealing
with this data to begin with. In addition, use the standard S_IFMT
macro for file type masking instead of hardcoded hex value.
Lose the duplicate detection introduced in commit
348eea3a41 which was a bit controversial,
and outside rpm's jurisdiction. Instead grab all the relevant file data
in through rpmfilesStat(). Simplifies things a good deal without really
losing anything, multiple user/groupnames will still be handled correctly
as long as they can be resolved to the same id via the normal means.
So from rpm's POV no functional changes, just 40 lines less goo...
In archives, hardlinked files are zero-sized except for the last file
of the hardlinked set which carries the actual content. For other
purposes we want the actual size, hardlink or not. So in rpmfilesStat()
always just report the size from the header and fixup the size to
when iterating over archives from rpmfiStat() instead.
Commit ec0d4d80d8 added a bunch of
perfectly innocent looking rpm queries to the rpmbuild test suite,
which however end up breaking "make distcheck". Really.
The problem is that these are executed without the testsuite run()
wrapper function so the rpm running environment isn't quite right
and because of that, when run deep from distcheck in a crazy
prefix config (or something like that), an rpmdb instance gets left
over where it shouldn't be, and that makes distcheck unhappy.
And that in turn tends to make your head hurt.
Regression introduced in commit 5b176ceca6
by the way of sloppy eyes: the main macros file used to be included
in the path via ${abs_top_builddir} but that's not where macros.debug
lives, unless you happen to build in the source directory directly.
The correct source for macros.debug is ${top_srcdir} instead.
Only follow directory symlinks owned by target directory owner or root
during verification to match the behavior of fsmVerify() in the new
CVE-2017-7500 world order.
The code is klunkier than it should and the logic should use common code
with fsmVerify() instead of duplicating it here, but that needs more
changes than is comfortable to backport so starting with this.
Also worth noting that the previous "follow the link" logic from
commit 3ccd774255 was not quite right,
it'd fail with RPMVERIFY_LSTATFAIL on a broken symlink when it should've
ran verification on the symlink itself. This behavior is fixed here too.
Finally, once again fakechroot gets in the way and forces the related
verify testcase to be changed to be able to create a valid link. Reuse
the replacement testcase for the purpose and add another case for
verifying an invalid link.
Only follow directory symlinks owned by target directory owner or root.
This prevents privilege escalation from user-writable directories via
directory symlinks to privileged directories on package upgrade, while
still allowing admin to arrange disk usage with symlinks.
The rationale is that if you can create symlinks owned by user X you *are*
user X (or root), and if you also own directory Y you can do whatever with
it already, including change permissions. So when you create a symlink to
that directory, the link ownership acts as a simple stamp of authority that
you indeed want rpm to treat this symlink as it were the directory that
you own. Such a permission can only be given by you or root, which
is just the way we want it. Plus it's almost ridiculously simple as far
as rules go, compared to trying to calculate something from the
source vs destination directory permissions etc.
In the normal case, the user arranging diskspace with symlinks is indeed
root so nothing changes, the only real change here is to links created by
non-privileged users which should be few and far between in practise.
Unfortunately our test-suite runs as a regular user via fakechroot and
thus the testcase for this fails under the new rules. Adjust the testcase
to get the ownership straight and add a second case for the illegal
behavior, basically the same as the old one but with different expectations.
These need an extra macros file which OTOH cannot be present in other
tests, but overriding --macros tends to get into different kinds of
trouble, for example commit ec0d4d80d8
revealed hardcoded /usr/local/lib/rpm prefixes in the cli invocations
by the way of test-suite failures when a different prefix is used.
The testsuite runs with RPM_CONFIGDIR pointed to the test environment
so basic rpm configuration is fine as-is, just arrange the macros.debug
file into the environment by copying and removing for each of these tests.
Crude yeah, but works. Loading the macro file with --eval "%{load:...}"
would also work but that would introduce extra newlines everywhere, which
is ugly and avoided by copying. Maybe we should add a special --load=...
cli switch just to load additional macros - this isn't the first time
somebody needed that.
Debuginfo packages are useful without debugsource files. But it is often
useful to also have the debugsource files. So make debuginfo packages that
don't contain sources recommend the debugsource package (or the main
debuginfo one if the sources are not in a separate debugsource package).
Add Package dbgsrc as argument to filterDebuginfoPackage so it can be
added as recommendation. Add a new function findDebugsourcePackage.
Use it to add a requires to the main debuginfo file and/or the debuginfo
subpackages.
Extend the various rpmbuild.at tests that create debugsource and/or
debuginfo subpackages to check the debugsource (or main debuginfo)
package is recommended.
Signed-off-by: Mark Wielaard <mark@klomp.org>
Also add the dependency tag as argument so it can be used to add either
a Requires or Recommends. Adjust the one caller to pass RPMTAG_REQUIRENAME.
Signed-off-by: Mark Wielaard <mark@klomp.org>
This is just a slightly simpler alternative to PR #187 with a more generic
name to leave room for future developments. The thing is, flushing out IO
is something rpm should really do always on *some* level, but on rotational
disks doing so on this simple per-file level is so horribly expensive that
it's simply not practical. SSD's are an entirely different story however,
and on some workloads regularly flushing out IO has other benefits (which
is what PR #187 is actually about) even if you dont actually care about the
durability aspects.
Documentation is intentionally left scarce as this is not at a stage
where we'd want to actually advertise it.
Open newly created files with O_EXCL to prevent symlink tricks.
When reopening hardlinks for writing the actual content, use append
mode instead. This is compatible with the write-only permissions but
is not destructive in case we got redirected to somebody elses file,
verify the target before actually writing anything.
As these are files with the temporary suffix, errors mean a local
user with sufficient privileges to break the installation of the package
anyway is trying to goof us on purpose, don't bother trying to mend it
(we couldn't fix the hardlink case anyhow) but just bail out.
Based on a patch by Florian Festi.
Back in 2011 "somebody" forgot to apply brain when copying the return
type of "long" from ftell() to the Ftell() implementations within rpmio
(commit 61f5838aa8).
Fast-forward six years and suddenly TexLive in Fedora no longer builds
on 32bit architectures due to that thinko, appearing to be a regression
in commit 7d1a303c45. However that only
exposes the inner flaw of Ftell() as the code now relies on values
past the initial header range, for which the 2G of "long" has been more
than enough on 32bit architectures too.
Doh, dude...
Directory names as stored in RPMTAG_DIRNAMES are not sorted when
separated from basenames, so binary search has no chance of working.
While a linear search on the dirnames would be guaranteed to find *some*
matches when they exist, it could still miss some results as the
matches are not guaranteed to exist in a neat low-high range.
Construct the entire pathname for prefix comparisons to ensure sorted
paths and adjust the file trigger testcase to cover this too.
Thanks to Pascal Terjan for initial investigations and Thierry
Vignaud for providing a workable reproducer.
In the distant past when rpm just stat()'ed all mounted filesystems,
it was quite necessary to have the option of disabling the fs stats.
However now that we only stat() filesystems we actually use, the
situation is quite the reverse: if stat() eg hangs, we wouldn't be
able to complete the transaction anyway so it's better to find that
out before the transaction even starts, regardless of problem filters.
Also the filesystem info sets could be used to track other things besides
space, such as suid/sgid availability, selinux and file caps support etc.
Non-zero transaction members is not a meaningful test for this, as we can
can fail early for several reasons. Only sync if we actually executed
rpmtsProcess().
If syncfs() is available (ie on Linux), only sync modified filesystems.
In order to do this, keep the diskspace information around throughout
the transaction.
Skip the sync entirely on chroot installations for now, but this
too should be configurable (always/auto/never or so).
There's a bit of a chicken-egg problem with post-transaction plugins:
for example systemd_inhibit should only be released after syncing,
but OTOH some other plugins might be performing actions whose results
should be syncing. Leaving it alone for now.
Prior to this, test-suite PYTHONPATH would be wrong for all but builds
using --prefix equal to system python location, and eg --prefix=/opt
would cause the testsuite to fall back to system rpm bindings instead
of the in-tree one. Ditto for dist-check.
The test-suite fails if python is not enabled. An alternative solution
could be disabling python tests when not enabled, but the python
tests cover things that are not covered elsewhere so especially
for dist cutting the tests are quite important.
distcheck runs from a read-only source tree so the packages that we
copy around for fuzzing "fuzz" have read-only permisssions and
modifications fail, causing the tests to fail. So instead copy the
to-be-modified packages from inside testing/data where the permissions
are taken care of by commit ecb4182655.
Bit hysterical that we haven't done this...
On Linux we could call syncfs() for only those filesystems that we
actually touched but somehow I doubt it's worth the trouble.
Another option might be doing this at rpmtxnEnd() but maybe that's
excessive.
An (A unless B) dependency implements (A and not(B)). This kind is useful
for "or" type dependencies, e.g. "Conflicts" or "Supplements".
As "Conflicts: (A unless B)" is equivalent to "Requires: (B if A)", I
thought this type is not needed. But there is no such equivalence
for Supplements, thus the change in mind.
Like with "if" we also have a syntactic sugar "else" flavor:
(A unless B else C) is the same as ((A unless B) or (B and C))
This commit also makes the "else" handling code in depends.c much
easier to understand.
Simplifies things a bit and also makes "PYTHON=python3 ./configure" work,
whereas it previously barfed on figuring the library names like
"libpython3.6m"
Triggers and file triggers can and do execute scriptlets from installed
packages which are not part of the current transaction and thus have no
associated transaction element, making the scriptlet callbacks
inconsistent and cumbersome for API users.
Create a fake transaction element for the poor orphan scriptlets lacking
one to make it consistent (of course, creating rpmte's with all their
associated data just to pass a header pointer along is ridiculously
expensive but *shrug*).
Regular triggers used to execute in the context of the triggering
transaction element, make them run with the owning trigger header too.
Mark Wielaard