This patch adds a generic plugin, exec.so, that should be sufficient for the
majority of Collection actions. After all packages in a Collection have been
installed/removed, this plugin executes the arguments by calling system(3),
allowing for a very generic and powerful method to perform many actions.
This also adds two sample macros as examples of the format, using the exec.so
plugin.
There are three times during a transaction when Collection actions can be
performed:
1) After the last time a member of a collection is either installed or removed
2) After the last time a member of a collection is installed only
3) Before the first time a member of a collection is removed only
This patch adds three lists to the rpmte structure to mark which transaction
elements fall into each of these groups, and the collections that caused that.
A new function is added to the TSM to scan through all the transaction elements
and update these lists. When a collection is added to one of these lists, it
signifies that when that transaction element is installed, the appropriate
action should be performed for that collection.
This patch adds a simple plugin system that makes simple problems easy to
solve, and difficult problems, such as SELinux, possible.
When the transaction gets to the point where a collection action should occur,
it expands a macro of the form %__collection_<collection name> to get the path
to a plugin and any additional options. The plugin is dlopen'ed, and the
appropriate function is called in the plugin, with the additional arguments
passed in.
This also adds a --nocollections option to disable performing Collection
actions.
This patch adds the install-time feature that if a package requires a package
in a collection, then it also requires all other packages in that collection.
This has the effect that collections will be roughly grouped together during a
transaction.
Although this is not absolutely necessary for the majority of collections, it
is required for the SELinux collection. This is because all SELinux policies
must be installed before the applications they secure to ensure correct labels.
This means we must ensure packages in the selinux collection are ordered
earlier in the transaction than all applications they protect. Adding this
implicit runtime requirements achieves this in a general manner, without major
modifications to dependency ordering.
To accomplish this, this patch splits the addRelation function into two parts:
one that determines which relations to add, and one that actually adds them.
After the usual relation is added between two packages, it then determines if
the required package contains any collections. If so, it finds all other
packages that are in the same collections and creates additional relations.
- We were adding a trailing newline to urlhelper command line passed
to execvp(), with the newline ending up in the URL passed to curl.
Many servers dont seem to mind the extra newline, but some do. Oh well...
- Just like suid/sgid bits, hardlinks to executables with capabilities
set can "leak" permissions to old, potentially vulnerable versions
of binaries. Related to RhBug:598775.
- Previously only actual package removal would clear s-bits from
s[ug]id files. This needs to be done on upgrade too to prevent
leaving vulnerable hardlinks of s[ug]id binaries around.
- What we'd really want to compare here is the color or ISA of the packages
but color isn't realiable as eg -devel packages often aren't correctly
colored, and ISA isn't currently available in the header as a standalone
entry. Comparing arch prevents otherwise reasoable i386 -> i686 type
arch changes on freshen but at least it avoids the most pathological
issues.
- RFC-4880 doesn't requires unix-style line-endings, we shouldn't either.
This is probably still oversly strict as RFC-4880 appears to permit
any whitespace to follow armor headers but ... shrug.
- On the principle of "no news is good news", if we already have the
keys to be imported, then everything is ok. The former behavior is
just confusing as witnessed in RhBug:462979
- Chroot is a process global state so it needs to be tracked globally.
A process can (in theory) have several transaction sets, each with
different roots (although only one can be active at any time), so
associating the chroot state with transaction set (as currently done)
is not right.
- "Reference count" chroot entering and exiting so callers dont need
to track the state changes individually when they need to go
in and out of chroot if not already done.
- This should probably go to librpmio eventually but as there are no
needs outside librpm currently, keeping this internal so we're free
to fiddle with the api if necessary
- the fsm thingie doesn't need to deal with chroot issues: except for
build where it doesn't matter, its only called from psm where the
chroot is already taken care of
- Eliminates some copy-paste slopping. Verify code traditionally only
shows the first attribute, take care to keep that format to avoid
breaking scripts unnecessarily
- Permits basic file verification with just a headerGet(), with some
caveats: there's no way to control which attributes get verified,
and there's no filtering of mtime differences of shared files. Those
aside, rpm -q --qf "[%{filestates:vflags} %{filenames}\n] <args>" now
performs the same as "rpm -V --nodeps --noscripts <args>"
- rpmVerifyFile() reports things as they are in reality - if timestamps
on disk differ to header then it reports it. Filtering on the result
belongs to the code interpreting the results.
- test verifyscript existence in rpmVerifyScript() instead of caller,
making it safe+correct for calling on any header
- eliminate unused/unnecessary arguments, local variables and bogus leftover
comments
- psm in test-mode is a no-op anyway, so dont bother at all with it
- also removes the need to check for test mode on pre/posttrans scripts,
these are now fully covered by psm too
- pass scriptFd and selinux enabled status as arguments from psm level
- selinux status could be queried directly with is_selinux_enabled()
but that's a fairly expensive call which does all sorts of funny
things and probably doesn't work at all in the average chroot
- Lua-scripts dont currently honor scriptFd and have no use for selinux
but pass the info there too as an early step towards supporting
scriptFd with Lua
- makes rpmScriptRun() even more of an argument monster, some of this
should probably go into rpmScript struct...
- switch root if necessary on entry and exit to psm already, nothing
inside the psm needs access to outside chroot
- eliminate chroot handling from scriptlet machinery, dealing with
chroot is a job for higher levels
- Lua scriptlets can change our cwd, always ensure we return to previous
cwd after executing by saving and restoring the cwd
- Besides there not being much point in having a separate source + header
for a small single function, this fixes build on case-insensitive
systems such as Mac OS X.
- The equivalent used to be possible in 4.4.x era as the value tables
were all exported, but this way we need to export far less
and the implementation details stay internal.
- rpmdsNew() returns NULL if the requested dependency type doesn't
exist in the header. The C-side API can handle NULL to all rpmds
"methods" and this is how librpm deals with non-existent sets rather
than waste memory on for empty ds structures. However the python side
wasn't expecting NULL for legal requests (but not setting error either)
and thus blowing up with SystemError exception.
- Raise TypeError on illegal arguments to rpm.ds constructor, and present
non-existent dependency sets as empty rpm.ds objects to python. This
lets python callers use iteration over ds items regardless of whether
the dependency actually exists or not. The alternative of returning
None (or raising exceptions) would break existing code for no
particularly good reason.
- a couple of important steps in chroot() in and out sequence missing,
causing "No such file or directory" whining on return from chroot()
unless cwd happened to be /
Steve Lawrence