[Geoserver-users] Role can edit in wrong workspace

Hartmut_Noack · January 18, 2014, 10:06pm

Hello,

I set up a role for users, that shall be allowed to edit only in one
workspace.

*.*.r=*
tan.*.w=TAN_GIS
tan_overlays.*.w=TAN_OVERLAYS
*.*.w=ADMIN,GROUP_ADMIN

The TAN_GIS role has no parent.
If I get the logic correctly this should result in:

- all roles can read everything
- ADMIN,GROUP_ADMIN can edit everything
- TAN_GIS can also edit in the tan workspace
- TAN_OVERLAYS can edit in the tan_overlays workspace

The goals is, to protect tan_overlays from being edited by anyone
except admin and users with role TAN_OVERLAYS.

Now, when I log in as a user with role TAN_GIS I get only the Layer
Preview secition, thus TAN_GIS-users cannot make use of their right to
write to anything.

So I changed this to:

tan.*.a=TAN_GIS

giving the TAN_GIS people the right to administrate(and inherently
read and write) this one workspace named tan.
Now the Layers-section is available for my TAN_GIS role but alas!

The user can actually edit layers in tan_overlays as well, I can set a
different shapefile and alter other stuff too, even though this role
should have reading access only.

What am I do wrong?

best regards

HZN

Christian_Mueller · January 19, 2014, 11:30am

Hi Hartmut

Read and wirte access mean reading/writing layer data and have nothing to do with layer configuration. Layer configuration is reserved to the admin.

Cheers
Christian

···

On Sat, Jan 18, 2014 at 11:06 PM, Hartmut Noack <zettberlin@anonymised.com> wrote:

Hello,

I set up a role for users, that shall be allowed to edit only in one
workspace.

..r=*
tan..w=TAN_GIS
tan_overlays..w=TAN_OVERLAYS
..w=ADMIN,GROUP_ADMIN

The TAN_GIS role has no parent.
If I get the logic correctly this should result in:

all roles can read everything

ADMIN,GROUP_ADMIN can edit everything

TAN_GIS can also edit in the tan workspace

TAN_OVERLAYS can edit in the tan_overlays workspace

The goals is, to protect tan_overlays from being edited by anyone
except admin and users with role TAN_OVERLAYS.

Now, when I log in as a user with role TAN_GIS I get only the Layer
Preview secition, thus TAN_GIS-users cannot make use of their right to
write to anything.

So I changed this to:

tan.*.a=TAN_GIS

giving the TAN_GIS people the right to administrate(and inherently
read and write) this one workspace named tan.
Now the Layers-section is available for my TAN_GIS role but alas!

The user can actually edit layers in tan_overlays as well, I can set a
different shapefile and alter other stuff too, even though this role
should have reading access only.

What am I do wrong?

best regards

HZN

CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In Between.
Get a Quote or Start a Free Trial Today.
http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

–

DI Christian Mueller MSc (GIS), MSc (IT-Security)
OSS Open Source Solutions GmbH

Hartmut_Noack · January 19, 2014, 12:00pm

Am 19.01.2014 12:30, schrieb Christian Mueller:

Hi Hartmut

Read and wirte access mean reading/writing layer data and have
nothing to do with layer configuration.

The webinterface *has* some tools (such as the Layers-section), that
allows to write new layers or is that considered "configuration"?

The webinterface *cannot* provide the tools for a role/user with
workspace_a.*.w to write anything and restrict them for others?

But when I connect to geoserver using Quantum GIS or similar software
with such a user-account it could? Or would I need to implement
external tools to manipulate data that could use such a role to access
the layers?

Basically we only collect SHP-files from several sources and configure
them for display via Google Maps on a public website(so the actual
data in the files is *not* to be edited in geoserver). But we need to
have different workspaces for files from different sources and with
different status. A scenario that is described in many use-cases and
tutorials and books.
We just do not want people from team A change a projection-setting or
the name of a layer set up by team B, by accident or intend: it should
be impossible...

Layer configuration is reserved to the admin.

OK, that would be a way to have my scenario working. Anyway:

workspace_a.*.a

should apply to "workspace_a" and *NOT* to any other workspace but it
seems to allow writing/configuration to *all* workspaces.

best regards

HZN

Cheers Christian

On Sat, Jan 18, 2014 at 11:06 PM, Hartmut Noack
<zettberlin@anonymised.com>wrote:

Hello,

I set up a role for users, that shall be allowed to edit only in
one workspace.

*.*.r=* tan.*.w=TAN_GIS tan_overlays.*.w=TAN_OVERLAYS
*.*.w=ADMIN,GROUP_ADMIN

The TAN_GIS role has no parent. If I get the logic correctly this
should result in:

- all roles can read everything - ADMIN,GROUP_ADMIN can edit
everything - TAN_GIS can also edit in the tan workspace -
TAN_OVERLAYS can edit in the tan_overlays workspace

The goals is, to protect tan_overlays from being edited by
anyone except admin and users with role TAN_OVERLAYS.

Now, when I log in as a user with role TAN_GIS I get only the
Layer Preview secition, thus TAN_GIS-users cannot make use of
their right to write to anything.

So I changed this to:

tan.*.a=TAN_GIS

giving the TAN_GIS people the right to administrate(and
inherently read and write) this one workspace named tan. Now the
Layers-section is available for my TAN_GIS role but alas!

The user can actually edit layers in tan_overlays as well, I can
set a different shapefile and alter other stuff too, even though
this role should have reading access only.

What am I do wrong?

best regards

HZN

------------------------------------------------------------------------------

CenturyLink Cloud: The Leader in Enterprise Cloud Services.

Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments & Everything In
Between. Get a Quote or Start a Free Trial Today.

http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk

_______________________________________________

Geoserver-users mailing list
Geoserver-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-users

Andrea_Aime4 · January 19, 2014, 1:41pm

On Sun, Jan 19, 2014 at 1:00 PM, Hartmut Noack <zettberlin@anonymised.com>wrote:

Am 19.01.2014 12:30, schrieb Christian Mueller:
> Hi Hartmut
>
> Read and wirte access mean reading/writing layer data and have
> nothing to do with layer configuration.

The webinterface *has* some tools (such as the Layers-section), that
allows to write new layers or is that considered "configuration"?

It is configuration, or, in our terminology, administration.
Writing is changing the _data_ in the layer, the attribute of a feature,
its geometry.

The webinterface *cannot* provide the tools for a role/user with

workspace_a.*.w to write anything and restrict them for others?

But when I connect to geoserver using Quantum GIS or similar software
with such a user-account it could? Or would I need to implement
external tools to manipulate data that could use such a role to access
the layers?

Access using OGC protocols is either "read" (WMS GetMap, GetFeatureInfo,
WFS GetFeature) or "write" (WFS Transaction), but never admin, the
only network protocol that allows for aministration is REST config
(http://docs.geoserver.org/stable/en/user/rest/api/index.html)

Basically we only collect SHP-files from several sources and configure
them for display via Google Maps on a public website(so the actual
data in the files is *not* to be edited in geoserver). But we need to
have different workspaces for files from different sources and with
different status. A scenario that is described in many use-cases and
tutorials and books.
We just do not want people from team A change a projection-setting or
the name of a layer set up by team B, by accident or intend: it should
be impossible...

> Layer configuration is reserved to the admin.

OK, that would be a way to have my scenario working. Anyway:

workspace_a.*.a

should apply to "workspace_a" and *NOT* to any other workspace but it
seems to allow writing/configuration to *all* workspaces.

Hmm... this seems like a bug, but I've never played with workspace specific
administration, so I cannot conmment

Cheers
Andrea

--
== Our support, Your Success! Visit http://opensdi.geo-solutions.it for
more information ==

Ing. Andrea Aime
@geowolf
Technical Lead

GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------