GeoServer

Data dir included in the .war distribution is wide open for the world to see...

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Blocker Blocker
  • Resolution: Fixed
  • Affects Version/s: 1.6.0, 1.6.1
  • Fix Version/s: 1.6.2
  • Component/s: Global
  • Labels:
    None
  • Number of attachments :
    0

Description

Basically everyone can see the contents of the data dir besides the services and catalog files that are explicitly hidden.
I'd say we reverse the situation, can we put the data dir into WEB-INF so that it's not visible at all unless we explicitly publish something with the file publisher?
Alternatively, it can stay there, we register the file hider to catch and hide everything into that dir. The file publisher is using paths other than data anyways, no?
(e.g. http://host:port/geoserver/www or http://host:port/geoserver/styles).

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Andrea Aime added a comment -

Tested the "move into WEB-INF" approach. Requires a minor modification to GeoserverDataDirectory and to the config maven plugin, and seems to work fine. The data dir behaves just like and external one as far as I can see. Simple and to the point, also avoids the need of the FileHider servlet hack (it's the way we used in 1.5.x. to hide services.xml and catalog.xml).
Shall I commit on 1.6.x, people do test it, and then we decide what to do about an eventual re-release? Or we roll out an emergency 1.6.2 by copying what's in the 1.6.1 tag?

Show
Andrea Aime added a comment - Tested the "move into WEB-INF" approach. Requires a minor modification to GeoserverDataDirectory and to the config maven plugin, and seems to work fine. The data dir behaves just like and external one as far as I can see. Simple and to the point, also avoids the need of the FileHider servlet hack (it's the way we used in 1.5.x. to hide services.xml and catalog.xml). Shall I commit on 1.6.x, people do test it, and then we decide what to do about an eventual re-release? Or we roll out an emergency 1.6.2 by copying what's in the 1.6.1 tag?
Hide
Permalink
Chris Holmes added a comment -

I suppose we should cut a quick 1.6.2 release, with just the one fix. It's fine if it's just what's in 1.6.1 plus this fix.

Show
Chris Holmes added a comment - I suppose we should cut a quick 1.6.2 release, with just the one fix. It's fine if it's just what's in 1.6.1 plus this fix.
Hide
Permalink
Andrea Aime added a comment -

Yeah, 1.6.x already has watermarking in, and I think most of the developer still haven't had a look at it. I would feel better doing an svn copy of 1.6.1 tag into 1.6.2, patch there, and re-release

Show
Andrea Aime added a comment - Yeah, 1.6.x already has watermarking in, and I think most of the developer still haven't had a look at it. I would feel better doing an svn copy of 1.6.1 tag into 1.6.2, patch there, and re-release
Hide
Permalink
Rob Atkinson added a comment -

it would be nice if on deployment Geoserver looked to see if a data dir was installed, and if not provided an option to choose it at the admin screen.

other requests would throw a meaningful error message of course

Show
Rob Atkinson added a comment - it would be nice if on deployment Geoserver looked to see if a data dir was installed, and if not provided an option to choose it at the admin screen. other requests would throw a meaningful error message of course
Hide
Permalink
Andrea Aime added a comment -

That would require a major change in how GeoServer is started up unfortunately, we'd have to make the Data class an indirection to the actual data class. At the moment Data loads the data dir content during the spring context startup, this basically mean, either the data dir is there where it's supposed to be, or GeoServer won't wire up properly and die.
I agree it would be advisable to do what you say, we have to consider it when we rewrite the config and ui subsystem.

Show
Andrea Aime added a comment - That would require a major change in how GeoServer is started up unfortunately, we'd have to make the Data class an indirection to the actual data class. At the moment Data loads the data dir content during the spring context startup, this basically mean, either the data dir is there where it's supposed to be, or GeoServer won't wire up properly and die. I agree it would be advisable to do what you say, we have to consider it when we rewrite the config and ui subsystem.
Hide
Permalink
Andrea Aime added a comment -

Tested a different approach which requires less modifications: we just stick the file hider servlet on the /data/* path and that effectively hides whatever is in the data dir. The file publisher then exposes just what we want.
This approach is better, Jody made me remember that we moved the data dir out of WEB-INF because otherwise under certain web containers it would have been unreachable (was that jboss? can't remember).

Show
Andrea Aime added a comment - Tested a different approach which requires less modifications: we just stick the file hider servlet on the /data/* path and that effectively hides whatever is in the data dir. The file publisher then exposes just what we want. This approach is better, Jody made me remember that we moved the data dir out of WEB-INF because otherwise under certain web containers it would have been unreachable (was that jboss? can't remember).
Hide
Permalink
Justin Deoliveira added a comment -

Integrated in geoserver-trunk #375 (See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/375/)

Show
Justin Deoliveira added a comment - Integrated in geoserver-trunk #375 (See http://gridlock.openplans.org:8080/hudson/job/geoserver-trunk/375/)

People

Vote (0)
Watch (2)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Codehaus. Try JIRA - bug tracking software for your team.