On Wednesday, August 24, 2011 9:55:55 AM UTC-4, Steve Modica wrote: > > Would a more acceptable solution for the generic case be to use port > forwarding and non-root apps that just access that port? > In that way, we could create simple apps to access our embedded device > router and not require setuid. >
Depends on what you are doing. Are you making a custom version of android? If not, it's not clear how you can open any of this up, other than hope that the device is rooted (and in the common way you expect). If you are making a custom version of android, having a service that listens on a tcp port (to keep things local, on the loopback interface _only_ or instead use a unix domain socket) would be one way to expose things, but it would not really offer much security in making it available to only some applications - it would differ from chmod'ing the device file itself to be world readable & writeable only in that your code would sit there arbitrating and mediating use of the device. To restrict access to only some apps, you'd need to add a unix group (to own the device file) and android permission (to assign membership in the group) to the android platform. Or you can keep the device file owned by a group only available to a java-style android service you package with the system, and have it check that a 3rd-party client app on the other end of the Binder IPC trying to use the service holds a desired android permission or otherwise qualifies as allowed. This probably belongs on android-porting rather than android-kernel -- unsubscribe: android-kernel+unsubscr...@googlegroups.com website: http://groups.google.com/group/android-kernel
