Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Handling java.lang.SecurityExceptions from sensors #4

Open
aaaaalbert opened this issue Feb 3, 2017 · 1 comment
Open

Handling java.lang.SecurityExceptions from sensors #4

aaaaalbert opened this issue Feb 3, 2017 · 1 comment
Assignees
Labels

Comments

@aaaaalbert
Copy link

It can happen that Sensibility doesn't have the permission to access a sensor. This then leads to an exception like this:

Exception (with type 'exceptions.Exception'): java.lang.SecurityException: getAllCellInfo:
Neither user 10106 nor current process has android.permission.ACCESS_COARSE_LOCATION.

How are we going to deal with this?

  • Make proper Python/Repy/Sensor exceptions. This makes sense in terms of handling these issues in a Repy program, but also means that handling is required! For every sensor in your program, you must always expect that the permission to use it is revoked. Thus, try/except everywhere.
  • Alternatively, hide these exceptions from the experiment. You try to access the sensor, but it ... returns None? The previous reading? Or it blocks indefinitely? Something else that makes sense?
  • The middle ground: Provide a wrapper layer, base the lower-layer implementation on (1), and provide (2) as the experimenter's interface. Downside: Messing with securitylayers to set the wrappers up.
@aaaaalbert
Copy link
Author

My current approach is to handle the SecurityException in Java already, and mask its existence by just returning null through JSON. That's not very beautiful, but we cannot do anything on the Python/Repy end anyway.

@aaaaalbert aaaaalbert self-assigned this Mar 7, 2017
aaaaalbert added a commit to aaaaalbert/sensibility-testbed that referenced this issue Mar 7, 2017
`SecurityException`s are raised when the app tries to access
a sensor which it isn't allowed (yet) to access. For example,
the user might not have seen the query for allowance, or they
deliberately turned off a previously granted permission through
the Android "app settings" GUI.

Anyway, this commit wraps the problematic calls in `MiscInfoService`
in `try/catch` blocks and just returns `null` for the sensors
values (or sub-values in the case of sensors returning dicts)
that the app isn't allowed to access.

The other sensor classes (location, media, output, sensor)
still need to be checked!

(In an ideal world, and if we only had to support higher API
levels, we could ask the user again and again whether they
want to grant the permission this time, and even provde them
reasons for why we think we should be granted acces. For now
however, it seems that hiding the `SecurityException` from
sandbox code is a relatively safe and sane thing to do.)
aaaaalbert added a commit to aaaaalbert/sensibility-testbed that referenced this issue Mar 7, 2017
This is in reference to SensibilityTestbed/repy_v2#4. If the user
doesn't give the ACCESS_COARSE_LOCATION or ACCESS_FINE_LOCATION
permissions, the various location-themed calls will fail with a
`SecurityException`.

With this commit, we catch this exception, and return `null`
for the missing location values.
aaaaalbert referenced this issue Mar 14, 2017
For the sensors that I currenlty mark as "bad", I see a RunBuiltinException
in my vessel log.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant