On Jan 21, 1:00 am, KaiGai Kohei <[email protected]> wrote: > * Again, the engine framework is not designed to host multiple modules > in usual way. If a security module occupies the engine framework, it > also has to load another module that provide physical storage engine, > by itself. (Or, security module also has to provide i/o feature? it > is quite nonsense.)
It's not *entirely* clear what you mean by this. I do use the engine to load multiple sub-engines that are separate and provide security isolation. > * The engine framework does not provide a hook just after a connection > from client is established. It is not a must-requirement. However, > we want to obtain privilege of the client process, and cache it in > the userspace. > If it is not available, we have to invoke a system-call for each > access control decision, but it will be expensive. It certainly does and I use it. You can see it here: http://github.com/northscale/bucket_engine/blob/master/bucket_engine.c#L433 > * The security module needs its private storage different from the storage > engine module. > Now, the conn structure has "void *engine_storage" to store an engine > private information, but the right to use is closed for the second > module. The engine should be aware of what you're doing with that data, so it can supply the API to manipulate it. > In addition, the hash_item structure does not provide any private > storage to store security context of the item (e.g this context will > record what process create this object). Well, no. Expanding the item structure is *very* costly. That should should be avoided where possible. That said, a given engine can define an item to look like whatever it wants after the base stuff. You'll notice the base structure doesn't even have a space for the key or data. > * The deployment of some hooks makes hard to decide what permission > should be applied. For example, process_bin_delete() calls "get" > method to confirm the object to be removed is existing. > But the "get" method is only chance for the engine module to know > a certain item is accessed in reader context. > Of course, if we consider "delete" is a combination of "read" and > "delete", it will be resolved. But it will damage the flexibility > of security design. This is a good time to be talking about this, as the engine API isn't dogma yet.
