Hi Glenn,
On 10/29/2013 01:02 PM, Glenn Schmottlach wrote:
Hi Daniel / Patrick -
Thanks for the feedback with respect to the kernel features ConnMan
expects to be available. It's certainly useful information to know
given the fact that we can't all use the latest kernel releases.
Certainly allowing ConnMan to fail "gracefully" when a needed kernel
feature is not present is much preferred.
With that said, I have a couple of questions related to the Session
implementation and design goals. Based on the documentation I've read
and the presentation Daniel gave in 2011 at Vancouver my questions
follow:
That presenation is a bit outdated. The main idea/goal is still
the same but the implementation details have changed.
1) It appears their is an assumption that the client "application"
belongs to a unique process, group, or Secure Linux context.
The smallest entity we can track is an process. We use
either UID, GID or SELinux (LSM) as a way to identify application.
So it is expect users of the Session API use one of
the above method to uniquily identify the application. That is
what we have currently in code. Maybe in future we can also
use cgroups but that is currently only plans.
2) The client application must explicitly do two things:
a) Bind to a specific device (SO_BINDTODEVICE). I am not clear why
that is necessary?
That has been removed. We use xt_owner instead now.
b) Mark the socket (and thus packets sent over that socket) with a
special "magic" number that is associated with the "mark" field in the
session configuration and used in the iptables configuration which
tracks statistics associated with that socket. It's not clear how this
"magic" number is shared between the application and ConnMan. Can you
clarify?
Since we use the xt_owner matcher we don't need to interact with the
application anymore.
There are few things that concern me with (a) and (b) above. As stated
in the presentation, there is no "free l lunch".
1) It appears that the client application must have "root" access in
order to set both the "SO_BINDTODEVICE" and "SO_MARK" socket options
(at least this is the case on my system). I suspect in all cases this
may not be advisable from a security/sandboxing standpoint. Was this
foreseen or am I missing something?
Exactly out of that reason we dropped this approach.
2) There appears to be an implicit assumption that the client
application has the ability to set atypical socket options (as above).
Certainly this is generally plausible for a C/C++ program but I wonder
if you've considered applications written in other languages (e.g.
scripting languages like Python, Lua, or Javascript) that may/may not
have direct access to those socket options.
That should now be resolved with using the xt_owner approach.
In particular, with HTML5
"apps" being all the rage today, how would you expect HTML5 "apps"
running in the context of a browser to set these options? These types
of applications may either run in their own process (the
Android/Chrome model) or perhaps still be part of a single WebKit
process and share the JavaScript VM with other "apps".
If the several application running in the same process, it is kind
of hard to figure out which app is opening a socket, unless
the WebKit/JavaScript VM is not providing some sort of information.
3) With respect to (2), I certainly see a future where some
applications will be implemented in HTML5. How would you see ConnMan
supporting applications in that environment. I am somewhat concerned
because your usual HTML5 developer's access to lower level sockets may
be hidden by either class libraries (e.g. Node.js) or browser
abstractions that don't give them the lower level access to the
features ConnMan seems to require for the "session feature.
I'm interested if you could elaborate on plans you may have for
supporting the scenarios I've described above. It's likely that I'm
merely ignorant of your overall design strategy and there is a clearer
path forward.
Always looking for contributions :)
cheers,
daniel
_______________________________________________
connman mailing list
[email protected]
https://lists.connman.net/mailman/listinfo/connman
