On Wed, 24 Apr 2013, Petr Vobornik wrote:
On 04/24/2013 06:03 PM, Alexander Bokovoy wrote:
On Wed, 24 Apr 2013, Petr Vobornik wrote:
I've implemented the remaining work. Pushed to the private repo.

Know problems & remaining work
1. Change generation of plugin index to dynamical instead of rpm-post

The plugin index (plugins.js) is generated by wsgi script. New dir was
created: /usr/share/ipa/wsgi to store the script. It has the same
attributes as migration dir.
Plugins.js should be located in /usr/share/ipa/ui/js/freeipa/ dir. New
rewrite rule was added in order to make it work. It has a nice side
effect that one could not find out that the file is dynamically
1. We should not elevate privileges to wsgi script. Instead, one could
do plugin list regeneration by running pre-start script in ipa systemd
unit. Alternatively, we can add ipa-js-plugins.service unit that is run
one-off and is required by ipa.service.

2. /usr/share/ipa/wsgi is wrong. In long term Fedora is moving to make
/usr/share read-only.

I'd rather moved it to /var/cache/ipa/wsgi. wsgi process already knows
how to reach to /var/cache/ipa/sessions so we are good from SELinux
perspective as well.

The wsgi script doesn't write anything. It just reads a content of /usr/share/ipa/ui/js/plugins directory, transforms it into JS AMD module with one array and returns it as an application/javascript http response.
Sorry, I've missed this part when looking through the code.

This approach is good then -- we don't modify anything on the file
system, only read.

My inspiration was /ipa/migration/migration.py. The difference is that plugins.py reads dir and migration.py communicates with LDAP through ipalib.

Is the reading of dir content also problematic?
That is completely fine -- after all serving those .js files implies
httpd_context_t being able to read them.

Sorry for false alarm!

/ Alexander Bokovoy

Freeipa-devel mailing list

Reply via email to