Hi Dan, On Wed, Feb 4, 2009 at 3:08 PM, Dan Williams <[email protected]> wrote: > 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.
I agree that they are different, but they all share the same need that is the authentication, and you also notice that already. >> 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. I don't think you have understand me, you cannot detect the process because when using signals you don't really need register, and if you do then it is even worse since there is only one process interested on it. Actually I should have enumerate a number 5. Useless wakeups >> 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. It can, it can stop the authentication right there. Power is important nowadays lets not emit a bunch of signals that nobody care but cause processes to wakeup. >> 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. Well you still need to emit a signal to tell the timeout expired, you will also need a method for agents to cancel it and probably use the bus id to make it safe that nobody else will screw the transaction. But if you are using the bus id why do you need to emit signals? I have to disagree with you about calling higher in the stack, here we need to call higher stack anyway either by emitting a signal or by calling a method, the difference is that by emitting a signal you can probably wakeup a lot more processes than by calling a method. > >> 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. Yeah, winner takes all, but if it fails do still proceed to next one? It would be funny to see connman and NM fighting for providing a credential to a connection (I know this is very unlikely to happen, but anyway). My point was about who to trust, and even though we can use PolicyKit or any other mechanism to make it safer when using signals you have to protect a lot more methods. >> 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. > Yep, the difference is that you need extra calls for doing error handling since you loose that when using signals. >> 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. Good so you don't always need to call the applet to ask for credentials. PS: To make it clearer, Im not saying that by using signals wimax authentication won't work, what Im trying to prove is that agents (the one that you have to register and are called back when necessary) *normally do a better job. If you need to track the bus-id it seems to be the less troublesome way. -- Luiz Augusto von Dentz Engenheiro de Computação _______________________________________________ wimax mailing list [email protected] http://www.linuxwimax.org/mailman/listinfo/wimax
