Chris Wright wrote: > It's more than that. What do you do for all the already running system > which lost its security state when you unplugged the module? And how do > you reinitialize everything when you re-insert it? Not an insurmountable > challenge, but the module must cope with this behaviour. Agreed. As I noted, in many of the modules I was interested in, there was no internal state to worry about. If you never unload modules WITH state, that's not an issue. > Let's just say, live code updates is not one of the primary goals of LSM. > In truth, it's not one of the goals of the kernel either. Now, live > updates of _policy_ is well within scope, and some security modules > support this already. Well said. But updating of policy is, in my mind, out of scope for a stacker; each module should figure out how to accept and implement policy changes, if they wish to do so. The main issue is just to make sure that the communication methods don't stomp on each other; using unique names in /proc, for example, resolves that. >>So Serge is working on a stacking solution already. Will his work, or >>something based on it, be accepted into the mainline in the near future? > > > Many incidental issues are popping up along the way. Those are being > dealt with and pushed upstream. As for full stacking, it's likely. That's great to hear! --- David A. Wheeler
This archive was generated by hypermail 2.1.3 : Wed Jan 05 2005 - 09:06:01 PST