-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2011 09:44 AM, Lennart Poettering wrote: > On Fri, 07.01.11 09:40, Daniel J Walsh ([email protected]) wrote: > >>> Hmm, can we start with an empty loaded policy and then load additional >>> parts of it as we go? i.e. if we encounter a socket /foo/bar/waldo we >>> ask libselinux to load /foo/bar, and so on? Most likely 90% of the >>> sockets will be in the same dir anyway (/var/run), so after the first >>> socket everything we need should be loaded most of the time. However, >>> since sockets can be configured dynamically to any place we might need >>> to load policy for other areas, too. Hence if we could load hte policy >>> bit by bit we should get relatively nice behaviour and only load a >>> minimal subset of the policy into memory. >>> >>> Lennart >>> >> I think the library functions are there to do this, but you would have >> to do the management of the paths. libselinux I believe does not have >> the capability to add a path after the initial load but you could have a >> link list of paths connected to blobs of regexes. > > So, instead of loading one single policy blob we would basically load a > number of independent policy blobs, but always only parts of the real > thing? I guess that is quite doable, though I do wonder how the prefix > finding algorithm should best look like... > > Lennart > Yes and you have a speed versus size thing. Do you want to compile /var once or /var/lock and /var/run or much worse /var/run/app1 and /var/run/app2 ...
I would not go above two directories. If you really want size versus speed you could free the blobs once you got to a steady state, if you can figure out you are in a steady state. And then reload them if you need too. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nLtIACgkQrlYvE4MpobNwcACglha7dxx5qst94OiSmCnNZWf7 SiUAoNhUGB1EKvX9Iu2HPRUFxw46WZ8B =eciC -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
