Hi all
@Justin, the modifications concerning GeoServerSecurityManager are
described in http://jira.codehaus.org/browse/GEOS-5101. The patch finishes
this concept we agreed on 17th of May. I added some additional
description.
@Andrea, the default xml role service is also affected by GEOS-5101. As an
example, a user can create two xml role services and add the identical role
(Let us call it ROLE_XXX) to both services. Then the role in the first
service is assigned to user1, the role in the second service is assigned to
user2. Now open the access control page for data or services. You will see
ROLE_XXX once. First confusion. You have to check what the actual role
service is and perhaps, you have to modify this setting. The patch avoids
such situations by checking uniqueness across all role services.
For access control, you need to see all the roles present in the system. At
the moment, you only see the roles of the actual role service. Next
confusion. Believe me, I tested with multiple role and user/group services
and I was confused by myself very often.
As you pointed out, most of the patch is about replacing deprecations.
During the deprecation work, I also found some bugs concerning wrong
assignments of deprecated constants to not deprecated constants and some
failures in the resource files, --> wrong or missing error messages. The
JDBC stuff also covers GEOS-5101 and bug fixes.
@Ben, the patch does not introduce new functionality. If finishes the role
concept which is already in trunk partially , but it does not work
correctly. The rest of the bug fixes is essential and I think, resolving
deprecations is not a major refactoring.
But anyway, if the patch goes not it, it is ok. I want to point out some
consequences.
1) The security systems requires a migration. Without the patch, I have to
split the migration into two steps, making things more complicated. The
second step is migration code for the role service.
2) Users using more than one role service may produce configurations
making step 2 of the migration impossible. (Additionally to the problems
described above).
3) If it is not possible to bring the changes at least to 2.2.1 but only
to 2.3.0, I have no idea how to continue. I even stopped working on the
security documentation because I am not sure how to describe things related
to roles.
Christian
2012/6/18 Ben Caradoc-Davies <[email protected]>
> Short version: I vote to hold the security patch until after RC and then
> apply it only to trunk.
>
>
> On 16/06/12 16:45, Christian Mueller wrote:
>
>> Waiting 4-6 weeks is no problem
>>
>
> It is worse than that. To clarify, when the RC is made, we will also be
> branching 2.2.x. Only essential bugfixes will made before 2.2.0 is
> released. New functionality will only be backported after testing on trunk
> and then only if low risk and with a PSC vote. Major refactoring is not
> allowed on stable.
> http://geoserver.org/display/**GEOS/GSIP+77+-+Time+boxed+**release+model<http://geoserver.org/display/GEOS/GSIP+77+-+Time+boxed+release+model>
>
> I voted +1 for GSIP 77.
>
>
> To close this issue, I need a decision of the PSC.
>>
>
> I vote to hold the security patch until after RC; this means that it will
> miss 2.2.x and only be applied to 2.3.x (trunk). Once it has been shown to
> work reliably on trunk, it might backported at some future date, but not if
> it requires major refactoring.
>
> Yes, this means that a lot of the new security functionality will suck on
> 2.2.0 and later stable.
>
> The purpose of the stable branch is to maintain stability, that it, to
> avoid introducing unpleasant surprises for users, such as new bugs,
> functional changes, or file format incompatibilities. It does not mean that
> stable is bug free, just that the behaviour of the software is known. Users
> should be able to upgrade a stable production system to a later patch
> version of the stable branch and have a reasonable expectation that nothing
> that was working will break. While security will be pretty hurty, that is
> just tough. It will be no worse than before your patch. New code equals new
> bugs. That is just the way it is. Stable is where we avoid adding bugs.
> While some users will feel pain, the herd will settle on one stable code
> base and learn how to cope.
>
> Releasing more often is a good practice. Andrea has done a great job on
> GSIP 77 and it would be a pity for our good intentions to be derailed so
> soon. No dessert until we eat all our vegetables.
>
> - Holding off releases has left stable so far behind app-schema on trunk
> that we have for over a year been warning users to never use 2.1.x for
> app-schema.
>
> - I know at least two other developers who have work that cannot go in RC
> and must go on trunk. Delaying RC blocks their work.
>
> Note that throughout, references to security mean security subsystem
> changes. Vulnerabilities to external attack (perhaps spelled "SECURITY"?)
> must always be patched on stable and trunk as soon as possible.
>
> Kind regards,
>
> --
> Ben Caradoc-Davies <[email protected]>
> Software Engineer
> CSIRO Earth Science and Resource Engineering
> Australian Resources Research Centre
>
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
