entrypoint_with_timeout decorator can be used with a timeout parameter,
if the timeout is reached PrivsepTimeout is raised.
The PrivContext has timeout variable, which will be used for all
functions decorated with entrypoint, and PrivsepTimeout is raised if
timeout is reached.
Co-authored-by: Rodolfo Alonso <ralonsoh@redhat.com>
Change-Id: Ie3b1fc255c0c05fd5403b90ef49b954fe397fb77
Related-Bug: #1930401
Currently all privsep calls use the same logging level as they use the
``oslo_privsep.daemon`` logger.
This creates a problem for services like nova where we don't want to
log its own privsep debug messages by default (even in debug mode) but
we want them for os-brick privsep calls.
This patch introduces a new string parameter to ``PrivContext`` called
``logger_name`` to control the name of the logger to use, which defaults
to ``oslo_privsep.daemon``.
Related-Bug: #1922052
Change-Id: Ie7cc25ed53563dd500f7b10ff43a48518d46a2e0
When a neutron agent starts up, it processes different resources
in separate eventlet threads. These can race creating the channel
which results in redundant privsep-helper processes. This patch
fixes that by adding a lock around channel creation.
Change-Id: I5de22b72059133b05d64be47f4c1d3f566b46a6e
Closes-Bug: #1864664
When nova-compute, an oslo.service, receives SIGHUP, running PrivContext
clients terminate, resulting in the shutdown of their corresponding
ClientChannel threads. Subsequent attempts to execute privileged methods
fail with EPIPE as a result.
The PrivContext._wrap'per (the meat of the entrypoint decorator) already
had a check to lazily start() the ClientChannel if that hasn't already
happened.
This commit makes ClientChannel store state indicating whether it's
still running; and adds logic to PrivContext._wrap to check that state
and reset (stop() and re-start()) the ClientChannel if it was previously
created but terminated.
Change-Id: I8096fc7fd014e6dd299fae8ab073336c7cae362a
Closes-Bug: #1715374
When generating a sample config, this shows
the real default behavior rather than recording
a number at sample config generation time.
Change-Id: I39e5200f795b52e61ab424a5fda4749086e458e2
We were missing the oslo-config-generator entrypoint in this library,
which meant there was no way to include the privsep opts in a
service's sample config file.
One complication is that it is possible to override the group name
for the opts. I assume this was done to allow services to run
multiple privsep daemons with different levels of permission, but
it means that the service will have to document any additional or
different group names that it may use.
Change-Id: I1ef30cb14d365f4bbfa580e75afc3580910d6fcf
When config_dir is set, we were seeing this error:
execv() arg 2 must contain only strings
We got this debug log:
['sudo', 'nova-rootwrap', ... ,
'--config-file', '/nova/nova.conf', '--config-dir', ['/etc/nova'],
...]
Change-Id: I592035f7e37adee375f1530d4fbc28107870b089
Closes-Bug: 1616240
Specifically, the goal here is to provide a default that can use
rootwrap.
This change implements a `priv_context.init` function that allows
oslo.privsep to hook into the startup of programs using oslo.privsep.
The intention is to call this function near the top of main() - after
oslo.config is available but before anything "interesting" is performed.
In this change, this init function just allows you to set the default
"run as root" prefix for helper_command to include something like
rootwrap.
In the future, it is expected to use this same call point to do other
"early" tasks like immediately forking privileged helpers and dropping
root if already running as root.
Change-Id: I3ea73e16b07a870629e7d69e897f2524d7068ae8
Partial-Bug: #1592043
oslo.privsep is not currently supported on Windows,
as it uses Linux-specific functionality (os.fork,
socker.AF_UNIX).
The client_mode should be set to False on Windows.
Change-Id: I545caa5528e629da477615f7e14d10602ad96abd
Closes-Bug: #1591122
This option needs to capture the current oslo_config in some way, so it
can be reconstructed in the new privileged process (when using the
'sudo/rootwrap' method). The previous version had a "$project"
placeholder default that didn't work in real usage (as expected). This
new version generates a default value at run-time based on the values of
cfg.CONF.{config_file,config_dir}.
If the deployer has provided an explicit value for `helper_command' then
the new cfg.CONF logic is also ignored.
Note secure deployments will capture this command line in sudoers or
rootwrap filters, and it is up to sudo/rootwrap to verify that whatever
we generate here is secure and reasonable.
Note also that this and the surrounding code is ignored when using the
'fork' method.
Change-Id: I0d31bf24cac6c26f10b5d1eebaa8f475402f73d2
LOG.warn is deprecated. It still used in a few places.
Updated to non-deprecated LOG.warning.
Change-Id: Ifa7e39d513c4f51a50b7516daa57f60141bbebb2
Closes-Bug:#1508442
This change adds a new `capabilities` kwarg to PrivContext, which
specifies the Linux capabilities to retain on the privileged side of
this context. This allows the privileged daemon to be run as root but
with restricted permissions, or as not-root but still with some limited
superpowers.
A new `capabilities` config option is added to the context config
section that overrides the default capabilities for that context. It is
expected that this will rarely be used.
Note that there is intentionally no way to specify "I want all
capabilities".
Change-Id: I61169d1d27609deb04115f4119654fd3d0690357
Supports starting privileged process via fork or sudo, and a thread-safe
client and server communication mechanism.
Coming in later changes:
- Extend json encoding to deal with non-unicode and more varied dict
keys (see test_comm.py).
- eventlet test case.
- Linux capabilities.
Change-Id: If6456631c51d4f2a1c95805ab9d6962b04f172bc
Implements: blueprint privsep
elajkat