So it seems that I can identify local changes by looking in the file
(pretty much as before really, except that the file is created using
semanage rather than vi).
Right... the idea behind semanage is that it should support multiple
backends. Right now it supports flat file, policy object representation
(via libsepol), and selinuxfs for booleans (via libselinux). In the
future we want to support more backends, such as LDAP, and a policy
management server being developed by Tresys. This server should allow
more fine-grained access controls over policy modifications than we
currently have with the flat file. Also, it should move towards
distributed management over a network.
So, while the representation is the same right now, it may not stay that
way in the future. We'll likely make the store readable only by semanage
utilities in enforcing mode.
One last thing: is it possible to add multiple objects in a single
semanage call?
I don't think the python frontend supports it, but the backend library
certainly does - it's transactional, and only the commit takes a long
time. It seems like this would be useful to people - Dan?
I ask because each one takes a while to run (to do the rebuild), and I
can imagine that in an RPM package where there might be lots of calls
to semanage being made in a %post scriptlet, it would be better to add
all the objects at once and only do a single rebuild.
Not sure of the status of rpm integration w/ modules, Dan would be the
person to ask...
Rpm would have to make use of the transactional mechanism, not only
because of speed, but because inter-module dependencies get resolved
that way [ speaking of which, do policy module dependencies match rpm
dependencies? ].
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
