I'm looking into sessions and have a situations where I could use some insight on how this should work or if you have thought of alternate ways to solve a problem I have.
We have a situation where we think we may need to proxy the session creation for the applications so we can provide extended filtering capabilities, etc. The session proxy is planned to play an administrative role for the applications to further abstract session creation among other things. However, it seems if we use the session-policy plug-in we have no way to proxy the session creation for an application because the uid is not optionally specified over a CreateSession DBus API but rather requested from DBus daemon itself. I wasn't sure if the design was to provide security by making use of the DBus uid API or if this was somewhat unintended. It also seems to force clients onto the system bus, was this also intended? What I am pondering is the ability to specify the uid or gid within the CreateSession API. This uid/gid then would become part of the "creation_data" that gets passed to the plug-in's create handler (policy_local_create). This would then allow the plug-in to use the user specified uid/gid instead of the DBus daemon uid/gid. If security is the main concern for the original implementation, then a couple possibilities come to mind: 1. The Create/DestroySession calls could be removed from the Manager interface and go into a new Session interface. This session interface could then be "locked-down" in the DBus system.conf so that only a specific user, in our use case the "session proxy", could access that interface. It would then be the task of the session proxy to authenticate the client application if needed. 2. The CreateSession would accept a uid or gid "override" value only from a specified uid/gid that is configured in the connman config file. Do any of these suggestions to my problem seem reasonable and/or match with the design intent/direction of the connman? Or, is there a better way to solve this problem, I am still very new to the connman. With my current understanding of the connman it seems like the ability to proxy session creation and management outside of the applications may have some benefit--at least in our current system. Tysen _______________________________________________ connman mailing list [email protected] https://lists.connman.net/mailman/listinfo/connman
