Limiting file system access to workspace administators, pre-proposal discussion

GeoServer GeoServer Developer
1

Hi,
in this mail I would like to discuss implementing a way to limit file system access
to workspace administrators (and maybe also more in general, to administrators).

Currently, one can browse the entire file system using the file source browsers for
coverage sources and file based data stores. The idea is to pose some limits so that
workspace admins are limited inside a well known sub-tree of the file system during
their GUI or REST administrative operations.

To keep things simple, I would propose, configuration wise, a simple template that
the (main) administrator would configure, e.g.:

/opt/data/{workspace}

When setting up a new store, the implementation would check if the current request
is an admin request (flag set by both GUI and REST API), and subject to validation
the path parameters in coverage and data stores.
The GUI would also be limited, so that areas that are not supposed to be accessible
are not showing up.

As a twist to help hosting, we might have the checks be performed also for the full
administrator, if the path template has been set by the system administrator through
an environment variable: while the best practice for production systems
is never to put data in the “data directory”, one is unlikely to like having a paying
customer freely wander over the entire file system.

Also, implementation wise, this does not seem neither a URLCheck (they are not
contextual to the type of request, nor related to admin usage) nor a
ResourceAccessManager related activity (which deals catalog access for all users
and all requests), and I don’t think we’d like to have these checks get disabled the moment
alternative resource access managers are installed.

Maybe a new FileAdminAccessManager interface?

public interface FileAdminAccessManager {
public boolean checkAccess(Autentication auth, File file);
}

The caller should be checking if the current request is an administrative request and the
current user is a workspace admin.

Thoughts?

2

Hi Andrea.

It would be indeed a great feature, especially to let the workspace admin autonomous when defining the styles!

Regards
Alexandre

Le jeu. 24 oct. 2024, 19:26, Andrea Aime via OSGeo Discourse <noreply@discourse.osgeo.org> a écrit :

aaime-geosolutions
October 24

Hi,
in this mail I would like to discuss implementing a way to limit file system access
to workspace administrators (and maybe also more in general, to administrators).

Currently, one can browse the entire file system using the file source browsers for
coverage sources and file based data stores. The idea is to pose some limits so that
workspace admins are limited inside a well known sub-tree of the file system during
their GUI or REST administrative operations.

To keep things simple, I would propose, configuration wise, a simple template that
the (main) administrator would configure, e.g.:

/opt/data/{workspace}

When setting up a new store, the implementation would check if the current request
is an admin request (flag set by both GUI and REST API), and subject to validation
the path parameters in coverage and data stores.
The GUI would also be limited, so that areas that are not supposed to be accessible
are not showing up.

As a twist to help hosting, we might have the checks be performed also for the full
administrator, if the path template has been set by the system administrator through
an environment variable: while the best practice for production systems
is never to put data in the “data directory”, one is unlikely to like having a paying
customer freely wander over the entire file system.

Also, implementation wise, this does not seem neither a URLCheck (they are not
contextual to the type of request, nor related to admin usage) nor a
ResourceAccessManager related activity (which deals catalog access for all users
and all requests), and I don’t think we’d like to have these checks get disabled the moment
alternative resource access managers are installed.

Maybe a new FileAdminAccessManager interface?

public interface FileAdminAccessManager {
public boolean checkAccess(Autentication auth, File file);
}

The caller should be checking if the current request is an administrative request and the
current user is a workspace admin.

Thoughts?

Visit Topic or reply to this email to respond.

To unsubscribe from these emails, click here.

3

I like your thinking, and had two related ideas from earlier that may interact.

  • The file browser dialog suggests several locations to administrators (the stay be what you intended by GUI would be limited)
  • An easy URL check added to for file system locations
  • What to do with the GEOSERVER_DATA_DIR/data/ location and directory structure … could we make this location configurable?

If we had your list of approved directories it could assist with these ideas.

I understand and respect your “twist” to help with hosting.

4

Hi Jody,

I like your thinking, and had two related ideas from earlier that may interact.

  • The file browser dialog suggests several locations to administrators (the stay be what you intended by GUI would be limited)

Yes, this is what I meant by limiting the GUI, so that the workspace admin cannot enter a location what would not be allowed.
This is only to be helpful, actual checks will be done along with a catalog add/save event, to ensure the limits are enforced
even if one is using the REST API.

One danger is the resource API, which is normally not available to workspace admins, but may be opened via the REST security:
I’ll add explicit documentation that this should not be done, or it will make the directory checks ineffective.

  • An easy URL check added to for file system locations

As indicated in the first mail, this has nothing to do with a URL check… the store locations are not covered by URL checks
because they can only be provided by an administrator, while URL checks are performed only in locations that may be provided
from the outside. It’s two different problems. Let me try to explain it also in another way.
The file system restrictions I’m proposing are to lock down the workspace administrator during store configuration, but once
configured, every user can use that store without any further check, it has nothing to do with request authorization, it’s admin only.
URLChecks instead are for all requests, and they happen to leak out to administration as well, because they are applied to
all requests, including admin ones, like an admin setting up an SLD pointing to an external icon.

  • What to do with the GEOSERVER_DATA_DIR/data/ location and directory structure … could we make this location configurable?

Using the “data” folder for a multi-tenant production system is a bad idea. Embedding data in the data directory has been allowed
to prepare self-contained data directories that can be zipped and sent around, as a “project delivery” mechanism and for demo
cases (like our default data dir), but it does not fit in a multi-tenant scenario where each workspace admin owns a slice of a larger
data directory, and where the data dir is “stable”, always in the same place, with WS admins having no access to it.
I’ll also clarify this in the documentation.

If we had your list of approved directories it could assist with these ideas.

It’s not a general list of approved directories, it’s a way to map a certain workspace admin to a place where they can place data,
be it rasters or file based vectors.
This allows to enforce:

  • Data isolation, each WS admin only sees its own data
  • Separate disk quotas per folder (availability subject to OS and file system, e.g. on Linux this is offered by XFS, although recent versions of ext4 seem to support it too)
  • Separate backup policies per folder

I understand and respect your “twist” to help with hosting.

Yes, this would help in the case where the georsever full admin and the system admin are meant to be
separate (hosting, or just larger organizations where the two figures are separate).

Cheers
Andrea

5

Using the “data” folder for a multi-tenant production system is a bad idea.

Yes, however some functionality has been developed assuming this bad idea.

it does not fit in a multi-tenant scenario where each workspace admin owns a slice of a larger
data directory, and where the data dir is “stable”, always in the same place, with WS admins having no access to it.
I’ll also clarify this in the documentation.

This is the hard coded use I am aware of:

  • “GEOSERVER_DATA_DIR/data/” used by the REST API
  • “GEOSERVER_DATA_DIR/uploads” used by importer and rest uploader

As you are defining a workspace configured file locations list, a separate proposal could allow the above to be configured for WSAdmin?

6

| jive Leader
October 25 |

  • | - |

This is the hard coded use I am aware of:

  • “GEOSERVER_DATA_DIR/data/” used by the REST API
  • “GEOSERVER_DATA_DIR/uploads” used by importer and rest uploader

As you are defining a workspace configured file locations list, a separate proposal could allow the above to be configured for WSAdmin?

Is rest-upload community module still in use? I thought we removed it ages ago… nope, the sources are still there,
but it’s still referencing restlet and would not compile. Safe to say nobody has been using it in ages, and its source code should be just removed.

For the REST API, indeed it’s defaulting to “GEOSERVER_DATA_DIR/data”, but we also have a RESTUploadPathMapper
extension point that can be enforce a different location.
The current implementation already allows to set up a different root per workspace (see RESTUploadExternalPathMapper)
So a simple solution would be to implement one that takes into account file system isolation, and if set, imposes the upload location to be there.
This mapper should be run last, so that the RESTUploadExternalPathMapper can be ignored (WS admins can edit their own WorkspaceInfo object,
that would allow them to access outside of their intended locations).

Importer wise, that’s an API available only to the full administrator (unless explicitly opened),
I don’t see an explicit “local workspace” awareness in the code… are you using it in a multitenant scenario, and if so,
can you elaborate on its intended usage, and how you’re protecting the system from abuse?
I’d lean to just document that usage of the importer is presently not compatible with workspace admin
file system isolation support.

Cheers
Andrea

7

Oh that is good to see RESTUploadPathMapper, is that a config option somewhere :slight_smile:

Yes I use importer, by the qgis bridge plugin, so used in all kinds of situations. I have patched a few importer problems to support the plugin.

I would happily fix it to use RESTUploadPathMapper if it is a documented / explainable approach?

8

As written above, it’s an “extension point”, originally defined in GSIP-114.

Code references to the current code:

image

As said, I’d have to create a new mapper implementation, that takes into account the file isolation template, and make sure it runs last, or just integrate it in the existing implementation.

I guess so, yes. And document the behavioral change.

Cheers
Andrea