What guarantees are there regarding config update timing? For example, if a process requires a policy change to get access to a required service, is the server guaranteed to get the config update before the service request?
When we bring in a filesystem, e.g. ram_fs, how does that affect things? It seems that the chain of asynchronous notifications would destroy timing guarantees.
Hi Ben,
On 27.02.2018 17:04, Nobody III wrote:
What guarantees are there regarding config update timing? For example, if a process requires a policy change to get access to a required service, is the server guaranteed to get the config update before the service request?
there are no guarantees of the timing of signals, not to speak of the response times to those signals by a server. Reconfiguring a server's policy and adding a client (matching the policy) at the same time cannot work reliably.
There are two approaches to overcome this problem.
In the case where you want to restrict access to the file system, you may plug the chroot component between the client and the server. This is the approach that I am using the depot-download subsystem (described in the release notes of the upcoming release). This side-steps the problem by not changing the server's policy dynamically.
Another principle idea is to defer the creation of the client until the server has somehow acknowledged the new policy. This approach is at work in the USB driver. The USB driver has a config option for reporting its active configuration. These reports give the feedback needed to decide when the policy for a new client is actually effective.
Cheers Norman
-
Nobody III -
Norman Feske