![[tokkee]](http://tokkee.org/images/avatar.png){kind=avatar}
diff --git a/doc/security.txt b/doc/security.txt
index 66f9f7eb83f473729c8ce852fe0440f9fc4f9fed..93c64f9e852adddee22018f301bd9dc8b71fc6a7 100644 (file)
--- a/doc/security.txt
+++ b/doc/security.txt
Security Mechanisms
===================
-:Version: $Revision: 1.13 $
+:Version: $Revision: 1.15 $
Current situation
=================
5. The command-line tool has no logical controls.
6. The anonymous control needs revising - there should only be one way to be
an anonymous user, not two (currently there is user==None and
- user=='anonymous).
+ user=='anonymous').
Possible approaches
- most user interfaces have multiple uses which can't be covered by a
single permission
-
Logical control
---------------
that implements the logical controls.
-Applying controls to users
-==========================
-
-Individual assignment of Permission to User is unwieldy. The concept of a
-Role, which encompasses several Permissions and may be assigned to many Users,
-is quite well developed in many projects. Roundup will take this path, and
-allow the multiple assignment of Roles to Users, and multiple Permissions to
-Roles. These definitions will be stored in the hyperdb. They don't need to be
-pushed to the actual database though.
-
-There will be two levels of Permission. The Class level permissions define
-logical permissions associated with all nodes of a particular class (or all
-classes). The Node level permissions define logical permissions associated
-with specific nodes by way of their user-linked properties.
-
-A security module defines::
-
- class InMemoryClass(hyperdb.Class):
- ''' Just be an in-memory class
- '''
- def __init__(self, db, classname, **properties):
- ''' Set up an in-memory store for the nodes of this class
- '''
-
- def create(self, **propvalues):
- ''' Create a new node in the in-memory store
- '''
-
- def get(self, nodeid, propname, default=_marker, cache=1):
- ''' Get the node from the in-memory store
- '''
-
- def set(self, *args):
- ''' Set values on the node
- '''
-
- class PermissionClass(InMemoryClass):
- ''' Include the default attributes:
- - name (String)
- - klass (String)
- - description (String)
-
- The klass may be unset, indicating that this permission is not
- locked to a particular class. That means there may be multiple
- Permissions for the same name for different classes.
- '''
-
- class RoleClass(InMemoryClass):
- ''' Include the default attributes:
- - name (String, key)
- - description (String)
- - permissions (PermissionClass Multilink)
- '''
-
- class Security:
- def __init__(self, db):
- ''' Initialise the permission and role classes, and add in the
- base roles (for admin user).
- '''
-
- def hasPermission(self, db, classname, permission, userid):
- ''' Look through all the Roles, and hence Permissions, and see if
- "permission" is there for the specified classname.
-
- '''
-
- def hasNodePermission(self, db, classname, nodeid, **propspec):
- ''' Check the named properties of the given node to see if the
- userid appears in them. If it does, then the user is granted
- this permission check.
-
- 'propspec' consists of a set of properties and values that
- must be present on the given node for access to be granted.
-
- If a property is a Link, the value must match the property
- value. If a property is a Multilink, the value must appear
- in the Multilink list.
- '''
-
- def addPermission(self, **propspec):
- ''' Create a new Permission with the properties defined in
- 'propspec'
- '''
-
- def addRole(self, **propspec):
- ''' Create a new Role with the properties defined in 'propspec'
- '''
-
- def addPermissionToRole(self, rolename, permissionid):
- ''' Add the permission to the role's permission list.
-
- 'rolename' is the name of the role to add 'permissionid'.
- '''
-
-Modules such as ``cgi_client.py`` and ``mailgw.py`` define their own
-permissions like so (this example is ``cgi_client.py``)::
-
- def initialiseSecurity(security):
- ''' Create some Permissions and Roles on the security object
-
- This function is directly invoked by security.Security.__init__()
- as a part of the Security object instantiation.
- '''
- newid = security.addPermission(name="Web Registration",
- description="Anonymous users may register through the web")
- security.addToRole('Anonymous', newid)
-
-The instance dbinit module then has in ``open()``::
-
- # open the database - it must be modified to init the Security class
- # from security.py as db.security
- db = Database(instance_config, name)
-
- # add some extra permissions and associate them with roles
- ei = db.security.addPermission(name="Edit", klass="issue",
- description="User is allowed to edit issues")
- db.security.addPermissionToRole('User', ei)
- ai = db.security.addPermission(name="View", klass="issue",
- description="User is allowed to access issues")
- db.security.addPermissionToRole('User', ai)
-
-In the dbinit ``init()``::
-
- # create the two default users
- r = db.getclass('role').lookup('Admin')
- user.create(username="admin", password=Password(adminpw),
- address=instance_config.ADMIN_EMAIL, roles='Admin')
- r = db.getclass('role').lookup('Anonymous')
- user.create(username="anonymous", roles='Anonymous')
-
-Then in the code that matters, calls to ``hasPermission`` and
-``hasNodePermission`` are made to determine if the user has permission
-to perform some action::
-
- if db.security.hasPermission('issue', 'Edit', userid):
- # all ok
-
- if db.security.hasNodePermission('issue', nodeid, assignedto=userid):
- # all ok
-
-Code in the core will make use of these methods, as should code in auditors in
-custom templates. The htmltemplate will implement a new tag, ``<require>``
-which has the form::
-
- <require permission="name,name,name" assignedto="$userid" status="open">
- HTML to display if the user has the permission.
- <else>
- HTML to display if the user does not have the permission.
- </require>
-
-where:
-
-- the permission attribute gives a comma-separated list of permission names.
- These are checked in turn using ``hasPermission`` and requires one to
- be OK.
-- the other attributes are lookups on the node using ``hasNodePermission``. If
- the attribute value is "$userid" then the current user's userid is tested.
-
-Any of these tests must pass or the ``<require>`` check will fail. The section
-of html within the side of the ``<else>`` that fails is remove from processing.
-
-Implementation as shipped
--------------------------
-
-A set of Permissions are built in to the security module by default:
-
-- Edit (everything)
-- View (everything)
-
-The default interfaces define:
-
-- Web Registration
-- Email Registration
-
-These are hooked into the default Roles:
-
-- Admin (Edit everything, View everything)
-- User ()
-- Anonymous (Web Registration, Email Registration)
-
-And finally, the "admin" user gets the "Admin" Role, and the "anonymous" user
-gets the "Anonymous" assigned when the database is initialised on installation.
-The two default schemas then define:
-
-- Edit issue, View issue (both)
-- Edit file, View file (both)
-- Edit msg, View msg (both)
-- Edit support, View support (extended only)
-
-and assign those Permissions to the "User" Role. New users are assigned the
-Roles defined in the config file as:
-
-- NEW_WEB_USER_ROLES
-- NEW_EMAIL_USER_ROLES
-
-
-Authentication of Users
------------------------
-
-Users must be authenticated correctly for the above controls to work. This is
-not done in the current mail gateway at all. Use of digital signing of
-messages could alleviate this problem.
-
-The exact mechanism of registering the digital signature should be flexible,
-with perhaps a level of trust. Users who supply their signature through their
-first message into the tracker should be at a lower level of trust to those
-who supply their signature to an admin for submission to their user details.
-
-
-Anonymous Users
----------------
-
-The "anonymous" user must always exist, and defines the access permissions for
-anonymous users. The three ANONYMOUS_ configuration variables are subsumed by
-this new functionality.
-
-
Action
======
access by admin users, and read-only by everyone else)
-Use cases
-=========
-
-public
- end users that can submit bugs, request new features, request support
-developer
- developers that can fix bugs, implement new features provide support
-manager
- approvers/managers that can approve new features and signoff bug fixes
-admin
- administrators that can add users and set user's roles
-system
- automated request handlers running various report/escalation scripts
-privacy
- issues that are only visible to some users
-