Previously, by default we would install our python modules into
/usr/lib/python/xen, for example /usr/lib/python/xen/__init__.py.
Upstream python's standard install location (a) includes the Python
version number and (b) puts things in site-packages by default.
Our best conjecture for the reason for this was an attempt to make the
installs portable between different python versions. However, that
doesn't work because compiled python modules (.pyc), and C python
extensions corresponding to one version of python, are not compatible
across different versions of python.
This is why upstream include the version number.
site-packages is the standard location for locally-installed packages
and is automatically included on the python search path.
In this change, we abandon our own unusual python path setup:
* Invoke setup.py in an entirely standard manner. We pass
PREFIX and DESTDIR using the appropriate options provided by
setup.py for those purposes (adding them to setup.py calls
which were previously lacking them).
* Since the installation locations are now on the standard
python path, we no longer need to add anything to the path
in any of our python utilities. Therefore remove all that
code from every python script. (Many of these scripts
unconditionally added /usr/lib/python and /usr/lib64/python which
is wrong even in the old world.)
* There is no longer any special `Xen python path'. xen-python-path
is no longer needed. It is no longer called by anything in our
tree. However since out-of-tree callers may still invoke it, we
retain it. It now prints a fixed string referring to a directory
which does not to exist; callers (who use it to augment their
python path) will thus add a nonexistent directory to their python
path which is harmless.
* Remove various workarounds including use of setup.py --home
(which is intended for something completely different).
* Remove tests for the XEN_PYTHON_NATIVE_INSTALL build-time
environment variable. The new behaviour is the behaviour which we
should have had if this variable had been set. That is, it is now
as if this variable was always set but also bugs in the resulting
install have been fixed.
This should be a proper fix for the bug addressed by c/s 19515.
Signed-off-by: Ian Jackson <ian.jackson@eu.citrix.com>
This patch changes the XML schema of the ACM policy to require a
version and that every conflict set have a name. Every VM label must
have one Chinese Wall Type and every resource label one Simple Type
Enforcement Type. As a consequence of this some example policies
needed to be changed. Also not offering that many configuration
options for compiling xen anymore to make things simpler.
Signed-off-by: Stefan Berger <stefanb@us.ibm.com>
be under /var/log/xen instead of under /var/log directly. This has
the advantage of cleaning things up a little and also can make it
easier to restrict the permissions needed by xend.
Signed-off-by: Jeremy Katz <katzj@redhat.com>
Subsequent patches will follow in the coming weeks that will enable
Xen ACM to control assignment of resources (e.g., block devices and
networking) to virtual machines based on resource labels and the
active security policy.
Signed-off-by: Bryan D. Payne <bdpayne@us.ibm.com>
Signed-off-by: Reiner Sailer <sailer@us.ibm.com>
integrate into Xen Management and which support the new access control
labels (labels replace the ssidref numbers at the management user
interface).
Signed-off by: Reiner Sailer <sailer@us.ibm.com>
creation/generation of the XML security policy files for the Xen ACM
security architecture. It is a python- based, web-based tool named
xensec_gen that allows users to create or modify XML policy files
through a browser. The resulting XML policy files can then be copied
or moved to the appropriate location in the /etc/xen/acm-security
directory structure in order to be translated into binary and used
within the Xen system.
Signed-off-by: Tom Lendacky <toml@us.ibm.com>
Keir Fraser