[22:18:51] <jstrom> hari: is /command url used by anything, or is it just left over since before jsonrpc? [22:30:00] <hari> jstrom: leftover [22:30:26] <hari> http://wiki.agocontrol.com/index.php/RPC#HTTP_GET_requests_.28OBSOLETE.21_This_might_be_removed_in_future_versions.29 [22:30:31] <hari> jstrom: ^ [22:31:15] <hari> jstrom: we can kick it i [22:31:23] <hari> n the trash [22:31:36] <hari> i wanted to remove it as soon as we introduce auth for jsonrpc anyway [22:33:31] <jstrom> everything is authed (basic auth) now, right? if enabled [22:34:09] <hari> yeah, that is just a hack until we have real auth via json-rpc [22:34:26] <hari> and some kind of a permissions system [22:34:41] <jstrom> any explicit plans? [22:35:05] <hari> only rough ideas [22:35:22] <jstrom> oaky [22:35:38] <tang2> hari: so how can i do that: replacing "libboost-xxx.49.0" by "libboost-xxx (>=1.49.0)" in debian/control file ? [22:35:47] <hari> i'm not yet sure how granular access control shall be, and how to let the user configure it [22:36:03] <jstrom> it's a tricky subject.. balancing security vs usability [22:36:06] <hari> tang2: iirc wheezy uses the 49 as part of the package name [22:36:42] <hari> jstrom: and the q is how far we want it to go.. shall just json-rpc do access control, or do we want it on the qpid layer, too [22:36:56] <hari> e.g. to restrict messagesend, use multiple qpid users, and so on.. [22:37:08] <hari> (also utlizing qpid acls) [22:37:50] <jstrom> yeah. [22:38:17] <hari> restrict just on device level, or also on specific commands, parameters, and so on [22:38:18] <jstrom> device-level security too? user X can accses lighting but not vent controlling [22:38:24] <jstrom> yea [22:38:42] <hari> but what my imagination still lacks is how to present that to the user [22:38:57] <hari> i've seen how folks can be burnt by LDAP ACIs ;-) [22:39:14] <hari> or iptables rules, or whatever with some complexity [22:39:40] <hari> and how to store them.. probably not in a .ini :-) [22:39:45] <jstrom> hehe [22:39:54] <jstrom> yeah.. teaching users security isn't easy [22:40:31] <jstrom> but i'm glad to hear there have been some thoughts on it :) [22:41:36] <hari> jstrom: if we'd work with multiple queues on qpid, we could restict specific users to specific queues, and have devices only on some queues, and so on [22:41:55] <hari> but things ain't get simpler by that.. [22:42:24] <jstrom> especially not if you want to add another users which uses both.. [22:42:48] <jstrom> I dont know too much about qpids security details [22:43:13] <jstrom> but I guess it cannot control on the contents of the message? i.e. to restrict command to a specific device, you'd still need ACLs in the end-node [22:43:25] <hari> you can do a lot, but not down to a message level afaict (at least with the topic exchange, but I might be wrong, as usual :-) [22:44:05] <hari> if we want filters based on message content, we probably need to implement them in agoclient [22:44:44] <hari> the other approach I was thinking about is to do all access control just in json-rpc [22:45:07] <hari> it is not like that "strangers" could talk to qpid directly anyway.. [22:45:43] <hari> with proper permissions on the config/messagesend and a non-default qpid pw, direct qpid access would be prevented [22:45:44] <jstrom> The issue is that agorpc would have to know about all details for every device.. [22:46:09] <hari> on the pro side, it would be a single level where we apply access control [22:46:18] <jstrom> and if you want to be paranoid, there could be bugs in other pieces which have access to the bus [22:46:25] <jstrom> yea [22:46:31] <hari> spliting rules to agorpc, qpid itself, agoclient and so on, wouldn faciliate either [22:47:27] <jstrom> another issue, what would i.e. agoevent or agoscenario be allowed to send [22:47:29] <jstrom> ? [22:47:34] <jstrom> anything, or limited on the user configuring it? [22:47:38] <hari> good q [22:47:53] <hari> and let's not forget that we have physical access to most devices controlled by HA software anyway [22:48:19] <hari> i mean i can restrict access to the light switch on the ago side, but physical access to the switch is still possible in most cases :-) [22:48:22] <jstrom> :D [22:48:23] <jstrom> yeah [22:48:44] <hari> so I think we should offer some protection [22:48:59] <hari> the q is if we need to become extremely paranoid and granular.. [22:49:33] <hari> good point with scenario and event, we would need per user events/scenarios then [22:50:02] <jstrom> I'd say there could be a few levels. configuration (adding7removing devices, changing names, moving around rooms), device-commands, readonly, none. [22:50:18] <hari> yeah, we need some "roles" for sure [22:50:20] <jstrom> s/I'd say/one idea/ [22:50:56] <jstrom> ok, so what if user a sets up a scenario which is evil, then we revoke the users rights.. is the scenario still usable, lurking there with it's evil code? ;) [22:51:35] <jstrom> or is the scenario banned, or just that part of the scenario which uses action xy.. [22:51:44] <hari> if we want to get that tight, agoclient needs to be involved, too [22:51:49] <jstrom> ep [22:51:50] <jstrom> yep [22:51:52] <hari> so teh scenario would run commands as user [22:52:00] <hari> and agoclient would check vailidty on each received command [22:52:23] <jstrom> yeah [22:52:34] <hari> if we make agoclient a lot more complex, we should think about using a python wrapper [22:52:44] <jstrom> around the c lib? [22:52:49] <hari> so that we don't have to duplicate everything from c++ client into the python client [22:52:49] <hari> yeah [22:53:38] <hari> per device and/or parameter ACLs should belong there [22:54:08] <hari> i wonder if we have the username in some qpid message field [22:54:34] <jstrom> well, are you going to trust a plain username in the qpidd message? or do you need cryptographically signed messages.. [22:54:37] <hari> agorpc would need to open multiple sessions per user [22:54:48] <hari> qpid uses sasl authentication [22:54:54] <hari> and we can also use ssl encryption [22:55:11] <jstrom> ah, direct end-to-end auth from end-user to the qpid broker? [22:55:31] <hari> that would be one possible approach, albeit needing some changes in agorpc [22:55:52] <hari> we could make multiple queues on the broker, e.g. a specific one for security system related commands, and so on [22:56:44] <hari> unfortunately acls are not dynamic in qpid, but there is a QMF command api which allows to tell qpid to reload the acl file [22:57:25] <jstrom> can we write ACLs from QMF? would want some UI for that, I guess [22:57:56] <jstrom> nah, I got to go to bed now.. this discussion will go on forever, got to break now ..: ) [22:58:00] <hari> but we still woudl need more granular control than qpid acls [22:58:14] <hari> e.g. agocontroller in agoresolver supports a lot of config commands, but also essential stuff [22:58:30] <hari> so this needs to be filtered based on command..