Security fix default user permissions

Default user permissions should not include all user attributes. We now
limit this to the username, realname and some further attributes
depending on the schema. Note that we no longer include the email
addresses, depending on your installation you may want to further
restrict this or add some attributes like ``address`` and
``alternate_addresses``.

Author: schlatterbeck

CHANGES.txt

@@ -6,9 +6,10 @@ and template changes not listed here.
 Each entry has the developer who committed the change in brackets.
 Entries without name were done by Richard Jones.
 
-**IMPORTANT** The v1.5.x releases of Roundup will be the last to support Python
-v2.5. Support for Python v2.5 will be dropped with the v1.6 release of Roundup,
-at which point users will need to run Roundup using either Python v2.6 or v2.7.
+**IMPORTANT** The v1.5.x releases of Roundup will be the last to support
+Python v2.5. Support for Python v2.5 will be dropped with the v1.6
+release of Roundup, at which point users will need to run Roundup using
+either Python v2.6 or v2.7.
 
 
 2014-??-??: 1.5.1
@@ -21,6 +22,8 @@ Pay attention:
   If you're upgrading from a previous roundup release version
   you should look into ``doc/upgrading.txt``.  (Ralf Schlatterbeck)
 
+  Also note the default user permissions, see ``doc/upgrading.txt``.
+
 Features:
 
 - The example local_replace.py has been updated to show how to link to
@@ -35,7 +38,7 @@ Features:
   class can be numeric -- in that case roundup will try to parse the
   value as an ID when evaluating form values -- not as a key. Specifying
   try_id_parsing='no' for these Link/Multilink will skip the ID step,
-  default is 'yes'.  (Ralf Schlatterbeck)
+  default is 'yes'. (Ralf Schlatterbeck)
 - New configuration option 'isolation_level' in rdbms section. Currently
   supported for Postgres and mysql, sets the transaction isolation level.
   Wrong history entries for concurrent database updates observed in
@@ -105,6 +108,12 @@ Fixed:
   (Thomas Arendsen Hein)
 - Fix issue2550841 roundup-demo templates not found in virtualenv (John
   Kristensen)
+- Security: Default user permissions should not include all user
+  attributes. We now limit this to the username, realname and some
+  further attributes depending on the schema. Note that we no longer
+  include the email addresses, depending on your installation you may
+  want to further restrict this or add some attributes like ``address``
+  and ``alternate_addresses``. (Ralf Schlatterbeck)
 
 Minor:
 - demo.py usage message improved: explains "nuke" now. (Bernhard Reiter)

doc/upgrading.txt

@@ -23,6 +23,23 @@ Contents:
 Migrating from 1.5.0 to 1.5.1
 =============================
 
+For security reasons you should change the permissions on the user
+class. We previously shipped a configuration that allowed users to see
+too many of other users details, including hashed passwords under
+certain circumstances. In schema.py in your tracker, replace the line::
+
+   db.security.addPermissionToRole('User', 'View', 'user')
+
+with::
+
+   p = db.security.addPermission(name='View', klass='user',
+       properties=('id', 'organisation', 'phone', 'realname',
+       'timezone', 'username'))
+   db.security.addPermissionToRole('User', p)
+
+Note that this removes visibility of user emails, if you want emails to
+be visible you can add 'address' and 'alternate_addresses' to the list
+above.
 If you have defined your own cgi actions in your tracker instance
 (e.g. in a custom ``extensions/spambayes.py`` file) you need to modify
 all cases where client.error_message or client.ok_message are modified

share/roundup/templates/classic/schema.py

@@ -101,7 +101,10 @@
 
 # May users view other user information? Comment these lines out
 # if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
+p = db.security.addPermission(name='View', klass='user', 
+    properties=('id', 'organisation', 'phone', 'realname', 'timezone',
+    'username'))
+db.security.addPermissionToRole('User', p)
 
 # Users should be able to edit their own details -- this permission is
 # limited to only the situation where the Viewed or Edited item is their own.

share/roundup/templates/devel/schema.py

@@ -292,8 +292,13 @@ def may_edit_file(db, userid, itemid):
 
 # May users view other user information? Comment these lines out
 # if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
-db.security.addPermissionToRole('Developer', 'View', 'user')
+p = db.security.addPermission(name='View', klass='user', 
+    properties=('id', 'organisation', 'phone', 'realname', 'timezone',
+    'vcs_name', 'username'))
+db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('Developer', p)
+
+# Coordinator may also edit users, so they may see everything:
 db.security.addPermissionToRole('Coordinator', 'View', 'user')
 
 # Allow Coordinator to edit any user, including their roles.

share/roundup/templates/jinja2/schema.py

@@ -101,7 +101,10 @@
 
 # May users view other user information? Comment these lines out
 # if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
+p = db.security.addPermission(name='View', klass='user', 
+    properties=('id', 'organisation', 'phone', 'realname', 'timezone',
+    'username'))
+db.security.addPermissionToRole('User', p)
 
 # Users should be able to edit their own details -- this permission is
 # limited to only the situation where the Viewed or Edited item is their own.

share/roundup/templates/minimal/schema.py

@@ -32,7 +32,9 @@
 
 # May users view other user information?
 # Comment these lines out if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
+p = db.security.addPermission(name='View', klass='user', 
+    properties=('id', 'username'))
+db.security.addPermissionToRole('User', p)
 
 # Users should be able to edit their own details -- this permission is
 # limited to only the situation where the Viewed or Edited item is their own.

share/roundup/templates/responsive/schema.py

@@ -292,8 +292,13 @@ def may_edit_file(db, userid, itemid):
 
 # May users view other user information? Comment these lines out
 # if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
-db.security.addPermissionToRole('Developer', 'View', 'user')
+p = db.security.addPermission(name='View', klass='user', 
+    properties=('id', 'organisation', 'phone', 'realname', 'timezone',
+    'username', 'vcs_name'))
+db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('Developer', p)
+
+# Coordinator may also edit users, so they may see everything:
 db.security.addPermissionToRole('Coordinator', 'View', 'user')
 
 # Allow Coordinator to edit any user, including their roles.

website/issues/schema.py

@@ -259,10 +259,13 @@ def may_edit_file(db, userid, itemid):
 
 db.security.addPermissionToRole('Coordinator', 'SB: May Classify')
 
-# May users view other user information? Comment these lines out
-# if you don't want them to
-db.security.addPermissionToRole('User', 'View', 'user')
-db.security.addPermissionToRole('Developer', 'View', 'user')
+# Allow Users and Developers to view most user properties.
+p =  db.security.addPermission(name='View', klass='user',
+   properties=('id', 'username', 'address', 'realname', 'phone',
+         'organisation', 'alternate_addresses', 'timezone'))
+db.security.addPermissionToRole('User', p)
+db.security.addPermissionToRole('Developer', p)
+# Coordinator may view all user properties.
 db.security.addPermissionToRole('Coordinator', 'View', 'user')
 
 # Allow Coordinator to edit any user, including their roles.