This repo was created by accident, use deb-python-oslo.privsep
instead.
Needed-By: I1ac1a06931c8b6dd7c2e73620a0302c29e605f03
Change-Id: I81894aea69b9d09b0977039623c26781093a397a
An exception is being thrown when tests are skipped if
the class name starts with Test causing the suite to
fail. Changing the name to .*Test fixes the problem.
Closes-Bug: #1609782
Change-Id: I8ef761a53737d82f1cf6288a655d014c98407e1c
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
Python2.7 has a bug that means the sockets returned from socketpair()
are not wrapped in the usual socket.socket class, and contain a broken
makefile() method.
This was important a long time ago when privsep used file
operations (and sock.makefile()) for communication. Privsep now uses
socket operations directly, and never calls makefile() on the
communication socket.
Further, the workaround breaks on py34 where the socket classes are
completely different (and don't have the original issue). Well past
time for the workaround to be removed and forgotten.
Change-Id: Id6395b8497b9f5449893e17d07fc4b664ee041ce
This change switches from JSON to msgpack for encoding messages on the
privileged channel. The binary encoding is faster(*) and msgpack's
primitives are a better fit for Python's. In particular, bytes and
non-string dict keys are supported without an additional layer of
encoding.
Note that lists are now converted to tuples across
serialization/deserialization, and this is the opposite of the previous
behaviour. There is no point modifying arguments to privsep
entrypoints, and this makes the values hashable (if desired) without an
additional conversion step.
(*) Since you asked: For a trivial arg/return value, this version is
about 1.5x faster than the previous json version - and many times faster
for non-trivial cases. Please focus on the "better fit for python's
datatypes" aspect however.
Change-Id: I4299c2fc059807610f83e12a2d470e020930c64c
The earlier[*] fdopen/GreenPipe workaround is ineffective in nova, since
it uses the wrong guard predicate. Nova doesn't monkey_patch `os`, so
this change switches to checking against `socket` module instead.
Neither of these is strictly "correct" for our os.pipe/fdopen case, but
we just want to get some indication of "is eventlet being used".
[*] fdopen change: I4a6c0d4247aca17536316fb0ab163241ad545b20
Change-Id: I2bba4c45a66f49d5014f218a0ce24f221c9196bd
The _fd_logger function works around a regular Unix pipe, with a python
file object wrapped around both pipe file descriptors. This would be
stupidly simple and obvious, except eventlet.
We need to use the fdopen from io.open(), and not os.fdopen() (on py2;
on py3 they're the same), because the older python file objects have
broken behaviour regarding blocking reads. Eventlet doesn't monkey
patch os.pipe, nor anything in io.* - so none of the existing eventlet
monkey_patching will "just work" for our case.
This change adds a custom `fdopen` function that explicitly uses
greenio.GreenPipe or io.open as appropriate - and uses this to always
return an eventlet-safe file object.
Change-Id: I4a6c0d4247aca17536316fb0ab163241ad545b20
When a context's 'capabilities' property was a non-empty list,
Daemon.run() would try to manipulate Linux capabilities, and fail if the
original user didn't already have (at least) these capabilities. This
is appropriate for the regular use case, but the intention of
UnprivilegedPrivsepFixture is that it would be a no-op that works for
zero-privilege test environments.
This change clears the capabilities list (setting/expecting zero
privileges) in UnprivilegedPrivsepFixture, as was originally intended.
Change-Id: I8a0d8275877a1f9e139127049b7e234003f901ea
This patch updates the setup.cfg to be consistent with the
daemon's usage of the name 'privsep-helper', instead of the
setup.cfg's name of 'privesep_helper'
Closes-Bug: #1543664
Change-Id: I02a6b9bf70fb1f75c75f2dad052b3d0ad9e96967
Previous code incorrectly used an explicit --config-dir=None on the
privsep-helper command line when cfg.CONF.config_dir was None (the
default). This change correctly skips the --config-dir flag entirely in
this situation.
Change-Id: I8d71b1e0c5ab702a39c3e56119611700a126a5d4
Follow new infra setup for translations, see spec
http://specs.openstack.org/openstack-infra/infra-specs/specs/translation_setup.html
for full details.
This basically renames
oslo.privsep/locale/oslo.privsep.pot to
oslo_privsep/locale/oslo_privsep.pot. For this we need to update
setup.cfg.
Update also domain name in i18n.py.
Change-Id: I72f8be0c6562741a2f7fb4d8171ec468e20716c5
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
Andreas Jaeger