SuDoh Design

From WebOS Internals
Jump to: navigation, search

Design Flowchart

Sudoh-Flowchart proposed.png

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