semanage / file_contexts.local

[Ivan Gyurdiev]

>
> 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? ].