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.
-
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.
-
Users using more than one role service may produce configurations making step 2 of the migration impossible. (Additionally to the problems described above).
-
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 <Ben.Caradoc-Davies@anonymised.com>
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
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 Ben.Caradoc-Davies@anonymised.com
Software Engineer
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
) and the problems Christian described with the JDBC extension are, if not a complete deal breaker, frustrating to someone who is not aware of the inner workings of security subsystem. An average user would have a bad time if he screws up the configuration the first time.