-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/07/2011 11:00 AM, Lennart Poettering wrote: > On Fri, 07.01.11 10:18, Daniel J Walsh ([email protected]) wrote: > >> 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. > > Hmm, so, I wonder how far we could get by just hardcoding that we preload > /var/run, /var/lock and /dev (the latter for /dev/initctl). That should > cover 100% of the sockets/fifos of a usual install. And if that doesn't > suffice we load the real deal on-demand. > > So, loading parts of the policy apparently takes up less memory. How > exactly is the speed of loading the policy influenced by this? I.e. is > loading a part of the policy as CPU/IO intensive as loading the full thing? > Or even more CPU intensive due to a lot of compares? Or cheaper? > > Lennart > I think it is just setup time. If all you are labeling in /dev is initctl, I would say just load that, /dev has lots of labels, that udev has to handle. The library is call regcomp on each line.
grep ^/dev /etc/selinux/targeted/contexts/files/file_contexts | wc -l 277 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0nQZEACgkQrlYvE4MpobMxSwCfTczLRvKuVly/APVLEhW3cp4P WRcAoLuzneawNoV1/JlWhSmMuvCsxLkq =cJj7 -----END PGP SIGNATURE----- _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
