In libselinux >= 3.1 these cause deprecation warnings on build.
security_context_t always was nothing but typedef to plain old "char *"
so just using that is entirely backwards compatible too.
Refactor the custom exec context setting code to look like setexecfilecon()
in case the real one is not available to eliminate pesky behavioral
differences between the two cases.
This fixes a concrete bug of libselinux setexecfilecon() returning with
an error when security_getenforce() returns with -1 (such as a bare
chroot with no /sys mounts etc), causing us to spit out useless error
messages in that case ever since fixing the bogus if-logic in
commit ab601b882b.
Fixes: #1077
We already filter out -EOPNOTSUPP and return OK, but the message was
getting logged before the filtering so we'd spit out spurious error
messages on filesystems that don't support SELinux (RhBug:1777502)
When there's an actual error, people will want to know without having
to rerun in verbose mode. Such as in RhBug:1641631 where configured
selinux policy differs from what is installed - the former message
error: Plugin selinux: hook tsm_pre failed
...is not particularly helpful to anybody, whereas this actually provides
some clues now:
error: selabel_open: (/etc/selinux/ponies/contexts/files/file_contexts) No such file or directory
error: Plugin selinux: hook tsm_pre failed
Besides unused, this has started spitting warnings in recent selinux versions:
In file included from selinux.c:5:0:
/usr/include/selinux/flask.h:5:2: warning: #warning "Please remove any #include's of this header in your source code." [-Wcpp]
#warning "Please remove any #include's of this header in your source code."
^~~~~~~
For a pre hook function display an error message and for a post hook
function display just a warning message. This corresponds with
the way how error/warning messages are displayed for scriptlets.
Also add a debug message into selinux plugin.
This function was factored out from rpm_execcon() upstream to make it
easier to use by its users, by making it not call execve() directly. It
is now also used by dpkg since 1.17.11.
Preserve the ad-hoc code for now so that it can be compiled against old
libselinux versions.
- Unowned directories obviously do not exist in rpmfi, so plugins
still need to be passed path and mode separately, but for all
the rest rpmfi is there and contains valuable additional information
that's been unavailable to plugins until now
- This is what rpm_execcon() in libselinux always did, and trying to
be more strict causes things to blow up on install to an empty
chroot where /proc and /sys/fs/selinux are not mounted.
- Now that the hook functions in plugins no longer need to be uniformly
named, rename them to more "natural" pluginname_hookname style so
__func__ (and gdb etc) give meaningful, distinct values for them.
No functional changes unless I typoed something.
- Change all plugin hooks to take plugin itself as the first argument,
adjust our existing plugins
- Further steps towards making plugins "instances" instead of
just semi-global blobs
- rpmplugins.[ch] implements the rpm internal plugin management
infrastructure, which is no business of anybody else. Mark the
symbols internal while at it.
- rpmplugin.h describes the API for the actual plugins, this is
to be made public once the API is considered stable enough (which
it certainly is not yet ;)
- Adjust our plugins to include the right header
- The in-rpm selinux code always ignored errors from selabel_lookup_raw(),
but the plugin version does. Apparently it can occasionally return
ENOENT as in "no context for this thingie here" for something which
causes the plugin version to return an error (I'm seeing this on
/var/lib/nfs/rpc_pipefs from nfs-utils)
- It's not rpm's business to say everything needs to have a label,
although this does seem a bit peculiar: for an arbitrary unknown
directory selabel_lookup() seems to normally return a "default"
context. Why that is not happening here I haven't got the slightest
idea, but then restorecon isn't complaining on this, why should we?
- Make the hook functions static now that its possible
- Directly include what the plugins need, dont include plugin.h
- Eliminate now unnecessary plugin.h
- Add a struct containing all hook function pointers to plugins,
let plugins populate it by themselves and call the hooks by the
hook struct, avoiding repeated dlsym() discovery on each call etc.
- Eliminate now unnecessary PLUGINHOOK_FOO typedefs, defines and the
"supported hooks" bitfield: supported hooks are whatever a plugin
declares in the struct. This also means the number of possible
plugin hooks is not limited by number of bits in an integer.
- This means the only symbol plugins need to export is <name>_hooks,
the actual functions can be static. This is not the case yet but
to avoid changing everything at once... this is already a fairly
big commit.
- This also fixes the nasty issue where in presence of multiple
(non-collection) plugins, supported hooks would not get called if
another plugin didn't support that hook because of
RPMPLUGINS_SET_HOOK_FUNC() using "return" on several cases,
which doesn't go very well with loops.
Panu Matilainen