[GRASS-dev] Implement a REST API for GRASS

GRASS GRASS developer
1

Dear devs,

In the last days I’ve started thinking to a REST API for GRASS.

I think would be nice to offer some of the GRASS functionalities through a web service.

I would like to detailed the whole REST API using the YAML format following the Swagger specifications/services, but before start the real work I would like to receive feedback on the idea…

I’ve tried to synthesize the concept in README let me know if you have comments and ideas, please feel free to open new issues or pull requests.

I see a major issue that is that: GRASS is using unix permissions to define the rules on who can access on what.

To preserve this part, the REST service must be executed as super-user in order to be able to execute a module as the owner of a specific mapset and all the user of the platform must be also user of the system.
The other option that I see is to execute the service as a normal user of the system who is the owner of all the gisbase, locations and mapsets, and the permission are checked before the execution of each module. The permission check must be implemented in a new layer on top of GRASS. With this solution the user of the platform are different from the user and group of the system.

Any ideas that you want to share?

Best regards

Pietro

2

On 24/05/17 13:18, Pietro wrote:

Dear devs,

In the last days I've started thinking to a REST API
<https://en.wikipedia.org/wiki/Representational_state_transfer&gt; for GRASS.
I think would be nice to offer some of the GRASS functionalities through
a web service.

I would like to detailed the whole REST API using the YAML
<http://www.yaml.org/&gt; format following the Swagger <http://swagger.io>
specifications/services, but before start the real work I would like to
receive feedback on the idea...

- first of all: is build a REST API for GRASS a stupid idea? should we
use/promote just the WPS?

Well, what is your argument agains WPS ? Why do you think a REST API is necessary / useful ?

AFAIK, there is no OGC standard for GIS REST services. There is one for WPS.

Moritz

3

2017-05-24 14:18 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear devs,

Any ideas that you want to share?

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Māris.

Best regards

Pietro

4

Hi Moritz,

···

On Wed, May 24, 2017 at 3:31 PM, Moritz Lennert <mlennert@club.worldonline.be> wrote:

  • first of all: is build a REST API for GRASS a stupid idea? should we
    use/promote just the WPS?

Well, what is your argument agains WPS ? Why do you think a REST API is necessary / useful ?

The main REST advantage, that I see, is that it is easier to explore and understand. If I need to perform just a simple operation I can navigate over the API and understand how to perform a request in few minutes, with no need to understand the protocol and the link between different elements…

The REST is not bonded to one single format (xml). JSON is easier/faster to read usually than xml and it is generally a better fit for data. REST allows better support for browser clients due to it’s support for JSON and generate a browser client for it should be quite straight forward. It seems like REST has better performance and scalability.

Nowadays REST services seems to be the industry standard (is internally used by Google, Amazon, Yahoo, etc)…

You may found further analyses here:
http://docs.opengeospatial.org/per/16-035.html#_advantages_and_disadvantages_of_using_rest

Respect to the WPS protocols a GRASS REST API has the advantage that don’t have to be a general standard for every possible processing service but can be specifically designed/optimized for GRASS.

So in my mind a GRASS REST API is just a simple and convenient way to expose some selected GRASS modules capabilities through a browser.

Best regards

Pietro

5

Dear Māris,

···

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more dangerous than exposing the same modules through a WPS service? Why?

Pietro

6

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear Māris,

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more
dangerous than exposing the same modules through a WPS service? Why?

Pietro

7

Seen this: https://bitbucket.org/huhabla/open-graas?
Cheers
Stefan
________________________________________
Von: grass-dev [grass-dev-bounces@lists.osgeo.org] im Auftrag von Maris Nartiss [maris.gis@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff: Re: [GRASS-dev] Implement a REST API for GRASS

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear Māris,

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more
dangerous than exposing the same modules through a WPS service? Why?

Pietro

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

8

2017-05-25 10:24 GMT+02:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Seen this: https://bitbucket.org/huhabla/open-graas?

Sorry, that shouldn't be public available. Please ignore this implementation.

Cheers
Sören

Cheers
Stefan
________________________________________
Von: grass-dev [grass-dev-bounces@lists.osgeo.org] im Auftrag von Maris Nartiss [maris.gis@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff: Re: [GRASS-dev] Implement a REST API for GRASS

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear Māris,

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more
dangerous than exposing the same modules through a WPS service? Why?

Pietro

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev
_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

9

It is no about implementation but the concept itself. As soon as there
will be an easy way how to provide GRASS GIS processing as a service,
somebody will run it without understanding all security ramifications
of allowing any input into GRASS. Securing GRASS code would be nice,
but so far we are short on high level developers who could do it.
I'm not voting against anyone making easy to run GRASS via WPS or
REST, I just want to be sure that lack security against various remote
threats is kept in mind.

Māris.

2017-05-25 11:24 GMT+03:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Seen this: https://bitbucket.org/huhabla/open-graas?
Cheers
Stefan
________________________________________
Von: grass-dev [grass-dev-bounces@lists.osgeo.org] im Auftrag von Maris Nartiss [maris.gis@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff: Re: [GRASS-dev] Implement a REST API for GRASS

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear Māris,

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more
dangerous than exposing the same modules through a WPS service? Why?

Pietro

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

10

2017-05-26 8:27 GMT+02:00 Maris Nartiss <maris.gis@gmail.com>:

It is no about implementation but the concept itself. As soon as there
will be an easy way how to provide GRASS GIS processing as a service,
somebody will run it without understanding all security ramifications
of allowing any input into GRASS. Securing GRASS code would be nice,
but so far we are short on high level developers who could do it.
I'm not voting against anyone making easy to run GRASS via WPS or
REST, I just want to be sure that lack security against various remote
threats is kept in mind.

This is true for all REST API's or WPS
that expose a legacy software functionality as internet service.
To reduce security risks you have to be in control of
the input (parameter, files, database) to the legacy software
and provide access only to trusted people via authentication.

Best regards
Sören

Māris.

2017-05-25 11:24 GMT+03:00 Blumentrath, Stefan <Stefan.Blumentrath@nina.no>:

Seen this: https://bitbucket.org/huhabla/open-graas?
Cheers
Stefan
________________________________________
Von: grass-dev [grass-dev-bounces@lists.osgeo.org] im Auftrag von Maris Nartiss [maris.gis@gmail.com]
Gesendet: Donnerstag, 25. Mai 2017 09:42
An: Pietro
Cc: GRASS developers list
Betreff: Re: [GRASS-dev] Implement a REST API for GRASS

I assume that both are equally dangerous. My opinion is that GRASS GIS
should not be exposed to any non trustable users, as various smaller
and larger bugs are too common. Unless, of course, it runs inside a
throw-away VM.

2017-05-25 10:33 GMT+03:00 Pietro <peter.zamb@gmail.com>:

Dear Māris,

On Wed, May 24, 2017 at 8:52 PM, Maris Nartiss <maris.gis@gmail.com> wrote:

GRASS GIS code has never been developed with security in mind. I would
not suggest to run it in a non-trustable environment.

Do you think that expose some GRASS modules through a REST API can be more
dangerous than exposing the same modules through a WPS service? Why?

Pietro

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev

_______________________________________________
grass-dev mailing list
grass-dev@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/grass-dev