[Zope-dev] CoreSessionTracking - "Access Session Data" permission

[Dieter Maurer]

Hi Chris,

in an earlier message, you defended the existence of a
separate permission "Access Session Data" (in the
CoreSessionTracking proposal) by the following
case:

	There may be (authenticated) users with
	(TTF?) scripting rights that should be prevented
	to screen session data (by withdrawing
	the "Access Session Data" permission from
	them).

This will only be effective, when not all users automatically
have the "Anonymous" role.

There was a discussion about the "Anonymous" role some
months ago in the list:

 * The (outdated) Content Manager Guide mentions that
   any user has the role "Anonymous".

 * A role "Anonymous" with the meaning
   "not authenticated" will make management for
   sites with authenticated, non-manager users
   more difficult, as those users should have most
   rights of "Anonymous".
   Only in exceptional cases, e.g. for session data,
   they will have less priviledges.

   If the meaning of "Anonymous" changes in this
   direction, then this role should be explicitely
   assignable to users in the "Change User" view
   to avoid such difficulties.


I would be much in favour of a solution that does not
entail new permissions. This would be possible,
if session id management and access to session data
would be melted together.

   In the current proposal, both are separate modules linked
   by the application:
      the application obtains a session id from the id manager
      and then accesses the session data, usually with the id,
      but in principle with anything it likes, e.g. a stolen session id.
   It seems that the new permissions should help to control
   such abuses.

   If the session id becomes an implicit (not DTML-forgable)
   parameter for session data access, then the session
   data need not to be protected by new permissions.

However, I agree with you, that even making session id management
implicit, will not provide strict security.


Why am I against new permissions?
This has partly to do with the current Zope permission management.
As soon as you have more than a few products installed and
created a few additional roles, permission management becomes
a nightmare: it is very difficult to keep the overview
with the current unstructured, non-batched permission setting
view.



Dieter