GSIP 229

GSIP 229 - File system access isolation

Overview

In this proposal new settings are discussed, that will allow a GeoServer administrator to limit file system access for workspace administrators, sandboxing each in a separate data sub-tree of competence.

In addition, the setting will also be available as a system or environment variable that a system administrator can configure. This will also limit file system access to the GeoServer administrator.

Proposed By

Andrea Aime

Assigned to Release

This proposal is meant for GeoServer 2.27, 2.26 and 2.25 (see also backwards compatibility notes).

State

• Under Discussion
• In Progress
• Completed
• Rejected
• Deferred

Motivation

When setting up a new store, a workspace administrator can browse the entire file system contents, in terms of directory and file names, within the limits of what the user running GeoServer can see. The same goes for the full GeoServer administrator. This is at the same time distracting and potentially dangerous: the full file system can contain many restricted information, and most of those won't be useful as a data source.

Proposal

Configuration

Allow to set up a directory in the file system, that is meant to be the root of all data managed by GeoServer. This matches a common practice, for example, under Linux systems, file-based data (raster or vector) is often located under a directory called /var/lib/geoserver (or a similar name under the /var tree).

A new "data sandbox" will be configured in the GeoServer interface. Every workspace admin will be isolated inside such data root following this pattern:

<data_root>/<workspace_name>

For example, if /var/lib/geoserver is configured as the data root from the UI, and a workspace administrator with access to workspaces ws1 and ws2 tries to configure a new store, GeoServer will only allow access to /var/lib/geoserver/ws1 and /var/lib/geoserver/ws2. In this same setup if the full administrator tries to configure a data store, the whole file system will be accessible.

/var
|--/lib
   |--/geoserver
      |--/ws1
      |--/ws2
      ...

However, if a system administrator sets up a GEOSERVER_DATA_SANDBOX through an environment variable, at that same location, then also the GeoServer full administrator will be limited to the contents of /var/lib/geoserver.

Implementation

Implementation-wise, we want to keep the GUI friendly while ensuring the file system access checks cannot be bypassed.

For a GUI-friendly experience, the FileInput component, used to indicate the location of a file or directory, will be modified as follows:

• The FileRootsFinder will be modified to expose only the accessible roots (e.g., the configured sandbox or the list of workspace specific sub-directories)
• The FileProvider, enumerating the files and directories in the file chooser popup, will be restricted to the available directories

At the same time, proper access will be enforced at the catalog level, during save and add operations, using the pre-add and modify events:

• Check the current request is an admin request (for either workspace or full admin, depending on the configuration)
• Check the datastore/coveragestore in question has a parameter pointing to the file system. In this context, we'll reuse the heuristics in ResourcePool.getParams for vector stores, and modify the CoverageReaderFileConverter for raster data.
• Check that file upload related activities in the REST API are restricted to the sandbox, by modifying the RESTUploadExternalPathMapper accordingly (enforcing the configured sandbox)

The above should cover both admin modifications from the GUI and the REST API.

Extensibility

The proposed implementation is expected to cover most common needs, but it might still not cover everyone specific requirements. As it's customary for GeoServer, the check and enforcement code will be based on an interface with a default implementation, allowing others to plug their specific logic if needed:

public interface FileAdminAccessManager {
    /** 
     * Returns the file system roots available for the current user 
     * (or <code>null</code> if there are no restrictions), eventually taking into account 
     * the current workspace, if any (optional property) 
     */
    public List<File> getAvailableRoots(Authentication auth, WorkspaceInfo ws);
 
    /** Checks if the specified file is accessible in the context of the current request */
    public boolean checkAccess(Autentication auth, WorkspaceInfo ws, File file);
}

Backwards Compatibility

When the new configuration item is not set, it won't perform any new check/restriction, this ensures backwards compatibility. The administrators enabling this on existing data directories might find it won't be possible to save stores pointing outside of the allowed sandbox (however, this is intended functionality).

Feedback

Voting

Project Steering Committee:

• Alessio Fabiani: +1
• Andrea Aime: +1
• Ian Turton: +1
• Jody Garnett: +1
• Jukka Rahkonen:
• Kevin Smith:
• Simone Giannecchini: +1
• Torben Barsballe: +1
• Nuno Oliveira: +1
• Peter Smythe: +1

Links

• Pull Requests GSIP-229