On Wed, 2009-02-04 at 00:54 -0300, Luiz Augusto von Dentz wrote: > Hi Dirk, > > If you check connman, BlueZ, obexd, you will find out how an dbus > agent works. They are meant for 'credentials' already since you can't Well, _one_ implementation of a dbus agent... Bluetooth is a fundamentally different interaction model than WiMAX, WiFi, VPNs, or 802.1x and understandably the authentication model is different. > use signals because they provide no feedback (no error/reply). If you > depend just on signals: There's nothing wrong with depending on signals. What matters is how the credentials get back to the WiMAX service in a trusted manner. The use of signals is an implementation detail. > 1. you will loose the ability to detect if there is any process that > can provide credentials In the simple model I've described, the connection manager is the process that supplies credentials, and it's up to the connection manager to determine the Agent. You're going to want to use the same Agent for all connection methods, be they WiFi, WiMAX, VPN, 802.1x, PPP, etc, to provide a consistent user experience. It would be pretty stupid to have each method implement their own Credentials API, and have the Agent implement 5 different D-Bus APIs. The Connection Manager already has to talk to each of these device-specific services, so it's already got the specialization to handle each method's authentication requirements. > 2. you won't be able to react on process responsible for credential > disconnecting from bus That's not actually a problem in the model I describe. If you choose a more complicated model (not the one I've described) where the WiMAX service assumes that a connection manager will not be available, and that the Agent is registered directly with the WiMAX service, you have to assume that the Agent will always be available. A process running in non-user context cannot activate a process running in user context, nor should it be able to for security's sake. D-Bus does not allow activation of a "session" (ie, user's session) service from a root-level process for this reason. Thus, you have to assume that the Agent, once registered, is always available. Were that agent to quit and disconnect from the bus, the WiMAX service can't do anything about it. > 2. no implicit timeout True; but a core service like the WiMAX service is a *service*, not a client, and should not be making method calls against some other service higher in the stack. Adding a manual timeout is trivial and 10 lines of glib code. > 3. anyone can reply and multiple replies can happen which are tricky > to define a good strategy who to trust Wrong. Replies can be protected by multiple mechanisms. Multiple replies are also not a concern for anyone who graduated a college CS course; once you have credentials, you transition immediately to an internal state in your state machine that does not need credentials, and thus any multiple replies are denied anyway. The same thing would happen for multiple Disconnect() calls; once you're disconnected, you're going to return an error if somebody calls that again. > In the other hand you may have a bigger problem since the > agent/process responsible for credentials will probably be either > connman or NetworkManager and both already have their own mechanisms > to collect credentials which could cause some problems such as NoReply I don't quite get what you refer to here with NoReply... could you explain more? Do you mean something with dbus? If that's the case then yes, the user may decide to cancel the connection process at any time, because they do not have their Credentials handy, and that's a problem that the WiMAX service needs to handle irregardless. Having the user cancel the connection when credentials are required is no different than the Agent returning an error when credentials are requested. > error. Although I expect connman to work it out since its storage is > accessible on the daemon which is not the case on NM that needs to > access its agents. NM accesses agents for credentials because it provides a lot of flexibility for things like one-time-pads/RSA tokens, retrying on wrong password, etc. For the case of NetworkManager system settings, the credentials are stored in protected storage that is always accessible to the daemon without user intervention, much like (I assume) connman. Dan
