SuDoh Design
Design Flowchart
The proposed specification for Sudoh uses a service and an application to control the running of applications as root. The service is initially asked by the 3rd party application to run a command. The service passes the arguments as "launch parameters" to the controller application, which then prompts the user for confirmation. If there is a stored action (allow/deny), then that stored action will be used rather than showing the user a dialogue box. If there is no stored action, the 3rd party application will be added to Sudoh's application list, and the user will be prompted for action.
The Sudoh application will allow users to change stored preferences for the Sudoh service. Example: an application requests root permissions and the user clicks allow, but forgets to select "Remember this action". The user can then enter the Sudoh application and change the preference value to "Always Allow" for that specific application. Other options will be "Always Deny" and "Always Ask".
UI Mockups
To be added tonight...
API Features
Here are the proposed API features for the Sudoh Application
Service API
This API is to be publicly exposed, so that one can make a simple service call from any application to request root access.
| Commands | ||
|---|---|---|
| Name | Type | Description |
| command | string | The name of the binary or script to be run. Required. |
| args | string | The arguments to be passed to the binary or script that will be run Optional. |
| verified | boolean | If set to true, the service will check to make sure that the calling application's appid is org.webosinternals.sudoh. If the check passes, the service will execute the command. If set to false or undefined, the service will call the Application API to prompt the user or use a stored decision. Optional. |
| Returns | ||
|---|---|---|
| Name | Type | Description |
| status | int | The execution status of the requested command. Returns -1 if the request was denied. |
| stdout | string | The stdout of the command |
| stderr | string | The stderr of the command. Only returned if there is output to stderr. |
Application API
This API, in the form of launch parameters, will be used internally to communicate with the c-service.
| Commands | ||
|---|---|---|
| Name | Type | Description |
| command | string | The name of the binary or script to be run. Required. |
| args | string | The arguments to be passed to the binary or script that will be run Optional. |
Sudoh Management Application
This application will allow the users to:
- View application that have requested root access
- View more information about the last command requested by an application
- Get details on a specific application (vendor, version, appid)
- Allow/Deny/Reset confirmation on any application that has asked for root permissions in the past.
- Remove an application from the list
The application will be a 'fat app', meaning it will contain both an Enyo version for webOS 3.X and a Mojo version for webOS < 3.X (Pre, Veer, Pre2)
Conversation Logs
Sep 26 03:06:10 <rwhitby> requesting app calls proxy app using launch params. Sep 26 03:06:22 <rwhitby> proxy app checks database. if ok, proxy app calls service. Sep 26 03:06:26 <IOMonster> ah Sep 26 03:06:29 <IOMonster> that sounds easier Sep 26 03:06:32 <rwhitby> service only accepts calls from proxy app. Sep 26 03:06:32 <rwhitby> done. Sep 26 03:06:48 <IOMonster> how hard would it be for an app to call ours? Sep 26 03:06:57 <IOMonster> since right now calling a service is fairly easy Sep 26 03:07:01 <rwhitby> it's a supported feature of webOS Sep 26 03:07:14 <rwhitby> launch parameters
17:46 IOMonster_desk: i'm thinking we should just do a "app X is allowed root access" 17:47 IOMonster_desk: but if they click "details" it'll let them view what command wants to be run 17:47 rwhitby: IOMonster_desk: do we have "allow once" and "allow always" options? 17:47 IOMonster_desk: a neat feature to do (but possibly a security risk if passwords are sent as arguments to a root application) would be to show the last commands ran by an app 17:47 IOMonster_desk: yep! 17:47 IOMonster_desk: rwhitby: it'll have a checkbox for "Remember" 17:48 IOMonster_desk: and it'll remember your decision if you click it 17:48 IOMonster_desk: else, it'll ask you every time 17:48 Jack87: IOMonster_desk, will there be a way to take the apps out of the allow always in the future if you change your mind? 17:48 IOMonster_desk: yep 17:48 IOMonster_desk: it'll have a manager app 17:48 IOMonster_desk: so you can go in and remove or blacklist apps 17:48 rwhitby: That's the SuDoh app, if you launch it from the icon 17:48 IOMonster_desk: any app that asks for permissions will be added to the list 17:48 IOMonster_desk: whether or not you click "remember" 17:48 IOMonster_desk: that way you can do an "always deny" 17:49 IOMonster_desk: if you forgetr to click "remember" the first time 17:49 IOMonster_desk: the manager app can be anywhere from super complex to super simple 17:49 IOMonster_desk: i'm going for a semi-complex setup 17:49 IOMonster_desk: a 2 pane design 17:50 IOMonster_desk: left pane is application names 17:50 IOMonster_desk: with an icon to the left of the name 17:50 IOMonster_desk: indicating "allow/deny" status 17:50 IOMonster_desk: tap on an app, and the right pane gives you more info about the app 17:50 Jack87: IOMonster_desk, youll have to setup two GUIs in that case one for mojo as well 17:50 IOMonster_desk: and possibly a list of the last commands that app ran 17:50 IOMonster_desk: Jack87: yep 17:50 IOMonster_desk: since i dont' know mojo (yet) it'll come second 17:51 rwhitby: or in parallel by someone else 17:51 IOMonster_desk: exactly 17:51 Jack87: it shouldnt be too bad oprolly just be devided into scences rather than panels 17:51 rwhitby: IOMonster_desk: that design will translate well to a phone app 17:52 rwhitby: front scene is list of apps in a scroller, tap on an app to get the details scene 17:52 IOMonster_desk: rwhitby: yep, that was what i was thinking 17:52 IOMonster_desk: basically, every time our app is asked to grant permissions, we'll store that app's name in our database 17:53 IOMonster_desk: er, if it doesn't exist already 17:53 IOMonster_desk: flow is as follows: 1) check if app is on allow/deny list 17:53 IOMonster_desk: 2) if on allow list, allow 17:53 IOMonster_desk: 3) if on deny list deny 17:53 IOMonster_desk: 4) if neither, store app name and present user with dialogue box 17:53 Jack87: how will the apps be identified? 17:53 IOMonster_desk: i'm thinking by name 17:54 IOMonster_desk: i think that's the only way we can 17:54 Jack87: hum multiple apps can have same name at least in launcher 17:54 IOMonster_desk: really? 17:54 IOMonster_desk: that's a bummer 17:54 rwhitby: need to do name, and appid in details 17:54 Jack87: rwhitby, whtats the technical term app id?> 17:54 Jack87: yup 17:54 IOMonster_desk: ah yep thats what i meant 17:54 Jack87: ah ok cool 17:54 IOMonster_desk: i didn't mean like "IORemote", more like com.thecubed.ioremote 17:55 rwhitby: appid is the unique key for the database