Recently upstream libselinux started providing a swig wrapper, named selinux.py. The problem is that this collides with our own pyrex wrapper, which is currently selinux.so. Fortunately python picks the .so, so portage still works, and the hardened's SELinux support does not yet use the upstream tools that use the wrappers, so we're ok for the moment. But we need to resolve the collision ASAP. Unfortunately I can't just remove python-selinux since it has more functionality than just wrapping libselinux functions. My idea is that we do this in two stages. In this bug we do stage 1, change everything over to selinux_aux.so, which is a renamed selinux.so. Then portage will require >=python-selinux-2.16-r1 for USE=selinux. In stage 2, (done in a future bug) when the portage that has this patch goes stable, we'll change as many functions over to the libselinux swig wrapper as possible, and remove selinux.so from python-selinux. This part is just a simple rename, please apply soon (2.1 and 2.0 branch if possible) so we can fix the collision ASAP. Again, the python-selinux dependency will have to be changed to >=python-selinux-2.16-r1.
Created attachment 79548 [details, diff] portage.py-selinux_aux-rename.diff This is made against the portage.py in 2.1_pre4-r1.
Created attachment 79593 [details, diff] backwards-compatible patch How about this (untested) patch instead? This makes portage try to import the renamed selinux_aux first and falls back to selinux if it cannot be imported. I'm afraid of circular dependencies with the other patch (if you install the renamed bindings before the patched portage.py or the patched portage.py before renaming the bindings selinux support stops working).
no, we can't do that. Like I said, not all of the functions of selinux_aux exist in the swig wrapper. And in the long run I want to switch over to the functions that are in the swig wrapper (same libselinux function, but they have different names in the wrapper and different returns).
also, right now the only available python-selinux has both selinux_aux.so and selinux.so. Hopefully by the time the portage that has this update goes stable, hopefully most selinux users will already have the right python-selinux. And with the right dep set, it should pull in the right python-selinux anyway.
I think we're misunderstanding each other here. Here's what I think the situation is: Older versions of python-selinux install selinux.so. Newer versions install selinux_aux.py (which provides the same functions selinux.so does, and depends on selinux.py from newer versions of libselinux to do so). If you "import selinux" when such a new python-selinux is installed you get libselinux's selinux.py which does not provide everything selinux.so did. Correct so far? With your patch applied portage will *only* work correctly with the new version of python-selinux installed (it only tries to import selinux_aux). However, portage without your patch will *only* work correctly with the old selinux installed (it only tries to import selinux). This is a problem: if you make portage depend on the newer python-selinux like you suggest there's nothing stopping people from upgrading to the new python-selinux first, then trying to upgrade portage in a new emerge run, which will not work since the old portage does not grok the new python-selinux. With my patch applied portage should work correctly with both the new and the old python-selinux: if the new one is there it will import and use selinux_aux, ignoring the selinux module. If the new selinux_aux is not there it will import selinux instead. Then python-selinux could depend on a portage version with that patch applied and the upgrade would be "safer": you can upgrade portage first (and the new portage will work with the old python-selinux just like the old one did) and then upgrade python-selinux (and it will start using selinux_aux). Please tell me what I'm missing :)
Well I realized there is an even safer upgrade path. The libselinux swig wrapper (selinux.py) looks like this: import _selinux is_selinux_enabled = _selinux.is_selinux_enabled is_selinux_mls_enabled = _selinux.is_selinux_mls_enabled getcon = _selinux.getcon . . . and creates all of these aliases for all of the library wrapper functions in _selinux.so. I can just add aliases in selinux.py to the functions to selinux_aux. Then there will be a nice compatability layer, and portage can switch over to the right functions in one shot, and not worry about compatability. I'll make a new patch.
Created attachment 80803 [details, diff] selinux_aux rename try 2 how about this patch. With this new setup, the python-selinux dependency should be >=dev-python/python-selinux-2.16-r2 instead of -r1 as I stated above.
*nudge* we really need to get this in stable and dev branches of portage.
ok, this has been sitting long enough that it doesn't apply anymore to the dev branch, I guess I'll have to rebase it :|
The multiple libraries thing is a little messy and I think it would nice to isolate them inside a new module called portage_selinux.
I don't agree with it being messy, but I'm not sure what you mean by isolate them in a new module. Make a dummy portage_selinux.py that just imports the two modules?
actually, since selinux_aux functions are just helper functions that eventually just call stuff in libselinux, a better option might be to just make a portage_selinux.py in portage itself, then only the selinux module would have to be imported. http://cvs.sourceforge.net/viewcvs.py/python-selinux/python-selinux/selinux_aux.prx?rev=1.1&view=auto Not all of that would be added, just the secure_* functions.
(In reply to comment #11) > Make a dummy portage_selinux.py that just imports the > two modules? Yes, because I'd rather not spread third party apis throughout the internals of portage. If we wrap the third party apis in a portage_selinux module, the dependency on those apis will be isolated (rather than dispersed throught the portage internals).
Created attachment 87430 [details, diff] new portage_selinux compatibility module This patch applies against 2.1_rc2-r2 and current svn. If this patch works then I'll go ahead and put it in, so please test.
Created attachment 87431 [details, diff] new portage_selinux compatibility module Fixed accidental attempt to import getcon from selinux_aux.
Created attachment 87433 [details, diff] new portage_selinux compatibility module Fixed is_selinux_enabled() == 1 logic. Sorry for the extra spam. :/
This is fixed in svn r3430.
This has been released in 2.1_rc3.
