Mercurial > p > roundup > code
annotate doc/security-history.txt @ 7723:8147f6deac9f
fix(db): Make using pg_service work again.
When I did the merge of schema support I broke pg_service.conf support
by replacing get_database_name with db_schema_split. This commit
fixes it.
Also this commit returns the schema if one is specified in
pg_service.conf.
back_postgresql.py:
Replace calls to db_schema_split() with get_database_schema_names()
(new name for get_database_name()). Rename db_schema_split to
_db_schema_split. It now returns a tuple (dbname, schema) rather
than a list. It is used only by get_database_schema_names() which
also returns tuples.
get_database_schema_names() can also get schema info for the service
(if present) as specified by pg_service.conf.
Add get_database_user() to get the user from either RDBMS_USER or
pg_service.conf. (User needed for creating schema, so not needed
before schema patch.
import re at the top of file and remove lower import.
Remove some schema code from db_command as it's not needed. The
database conection is done to either postgresql or template1
existing databases. This command never connects to the roundp
specified db.
test/test_postgresql.py:
Reorganize top level imports, add import os. Replace import of
db_schema_split with get_database_schema_names. Also replace calls
to db_schema_split.
Create new Opener for the service file. Set PGSERVICEFILE to point
to test/pg_service.conf.
Add three new classes to test Service:
1) using regular db
2) using schema within db
3) Unable to parse schema name from pg_service.conf.
The last doesn't need a db. Number 1 and 2 reuse the tests in ROTest
to verify db connectivity.
test/pg_service.conf:
three service connections for: db only, db and schema, and incorrectly
specified schema test cases.
doc/upgrading.txt:
updated to current status. Included example schema definition in
service file.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 28 Dec 2023 15:13:42 -0500 |
| parents | 485cecfba982 |
| children |
| rev | line source |
|---|---|
| 7092 | 1 .. meta:: |
| 2 :description: | |
| 3 Security mechanism implementation document for historical purposes. | |
| 4 | |
| 5 :orphan: | |
| 6 | |
|
7322
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
7 ============================= |
|
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
8 Old Security Mechanisms Notes |
|
485cecfba982
Simplify TOC; older docs pushed a level down; Consolidate debugging
John Rouillard <rouilj@ieee.org>
parents:
7092
diff
changeset
|
9 ============================= |
| 3940 | 10 |
| 11 Current situation | |
| 12 ================= | |
| 13 | |
| 14 Current logical controls: | |
| 15 | |
| 16 ANONYMOUS_ACCESS = 'deny' | |
| 17 Deny or allow anonymous access to the web interface | |
| 18 ANONYMOUS_REGISTER = 'deny' | |
| 19 Deny or allow anonymous users to register through the web interface | |
| 20 ANONYMOUS_REGISTER_MAIL = 'deny' | |
| 21 Deny or allow anonymous users to register through the mail interface | |
| 22 | |
| 23 Current user interface authentication and controls: | |
| 24 | |
| 25 - command-line tool access controlled with passwords, but no logical controls | |
| 26 - CGI access is by username and password and has some logical controls | |
| 27 - mailgw access is through identification using sender email address, with | |
| 28 limited functionality available | |
| 29 | |
| 30 The web interface implements has specific logical controls, | |
| 31 preventing non-admin users from accessing: | |
| 32 | |
| 33 - other user's details pages | |
| 34 - listing the base classes (not issues or their user page) | |
| 35 - editing base classes | |
| 36 | |
| 37 Issues | |
| 38 ====== | |
| 39 | |
|
4732
8ee41c7372e7
doc: Fix some Sphinx warnings.
anatoly techtonik <techtonik@gmail.com>
parents:
4567
diff
changeset
|
40 1. The current implementation is ad-hoc, and not complete for all use cases. |
| 3940 | 41 2. Currently it is not possible to allow submission of issues through email |
| 42 but restrict those users from accessing the web interface. | |
| 43 3. Only one user may perform admin functions. | |
| 44 4. There is no verification of users in the mail gateway by any means other | |
| 45 than the From address. Support for strong identification through digital | |
| 46 signatures should be added. | |
| 47 5. The command-line tool has no logical controls. | |
| 48 6. The anonymous control needs revising - there should only be one way to be | |
| 49 an anonymous user, not two (currently there is user==None and | |
| 50 user=='anonymous'). | |
| 51 | |
| 52 | |
| 53 Possible approaches | |
| 54 =================== | |
| 55 | |
| 56 Security controls in Roundup could be approached in three ways: | |
| 57 | |
| 58 1) at the hyperdb level, with read/write/modify permissions on classes, items | |
| 59 and item properties for all or specific transitions. | |
| 60 2) at the user interface level, with access permissions on CGI interface | |
| 61 methods, mailgw methods, roundup-admin methods, and so on. | |
| 62 3) at a logical permission level, checked as needed. | |
| 63 | |
| 64 In all cases, the security built into roundup assumes restricted access to the | |
|
4567
32b24abfe98e
Documentation polishing.
Eric S. Raymond <esr@thyrsus.com>
parents:
4557
diff
changeset
|
65 hyperdatabase itself, through operating-system controls such as user or group |
| 3940 | 66 permissions. |
| 67 | |
| 68 | |
| 69 Hyperdb-level control | |
| 70 --------------------- | |
| 71 | |
| 72 Control is implemented at the Class.get, Class.set and Class.create level. All | |
| 73 other methods must access items through these methods. Since all accesses go | |
| 74 through the database, we can implement deny by default. | |
| 75 | |
| 76 Pros: | |
| 77 | |
| 78 - easier to implement as it only affects one module | |
| 79 - smaller number of permissions to worry about | |
| 80 | |
| 81 Cons: | |
| 82 | |
| 83 - harder to determine the relationship between user interaction and hyperdb | |
| 84 permission. | |
| 85 - a lot of work to define | |
| 86 - must special-case to handle by-item permissions (editing user details, | |
| 87 having private messages) | |
| 88 | |
| 89 | |
| 90 User-interface control | |
| 91 ---------------------- | |
| 92 | |
| 93 The user interfaces would have an extra layer between that which | |
| 94 parses the request to determine action and the action method. This layer | |
| 95 controls access. Since it is possible to require methods be registered | |
| 96 with the security mechanisms to be accessed by the user, deny by default | |
| 97 is possible. | |
| 98 | |
| 99 Pros: | |
| 100 | |
| 101 - much more obvious at the user level what the controls are | |
| 102 | |
| 103 Cons: | |
| 104 | |
| 105 - much more work to implement | |
| 106 - most user interfaces have multiple uses which can't be covered by a | |
| 107 single permission | |
| 108 | |
| 109 Logical control | |
| 110 --------------- | |
| 111 | |
| 112 At each point that requires an action to be performed, the security mechanisms | |
| 113 are asked if the current user has permission. Since code must call the | |
| 114 check function to raise a denial, there is no possibility to have automatic | |
| 115 default of deny in this situation. | |
| 116 | |
| 117 Pros: | |
| 118 | |
| 119 - quite obvious what is going on | |
| 120 - is very similar to the current system | |
| 121 | |
| 122 Cons: | |
| 123 | |
| 124 - large number of possible permissions that may be defined, possibly | |
| 125 mirroring actual user interface controls. | |
| 126 - access to the hyperdb must be strictly controlled through program code | |
| 127 that implements the logical controls. | |
| 128 | |
| 129 | |
| 130 Action | |
| 131 ====== | |
| 132 | |
| 133 The CGI interface must be changed to: | |
| 134 | |
| 135 - authenticate over a secure connection | |
| 136 - use unique tokens as a result of authentication, rather than pass the user's | |
| 137 real credentials (username/password) around for each request (this means | |
| 138 sessions and hence a session database) | |
| 139 - use the new logical control mechanisms | |
| 140 | |
| 141 - implement the permission module | |
| 142 - implement a Role editing interface for users | |
| 143 - implement htmltemplate tests on permissions | |
| 144 - switch all code over from using config vars for permission checks to using | |
| 145 permissions | |
| 146 - change all explicit admin user checks for Role checks | |
| 147 - include config vars for initial Roles for anonymous web, new web and new | |
| 148 email users | |
| 149 | |
| 150 The mail gateway must be changed to: | |
| 151 | |
| 152 - use digital signatures | |
| 153 - use the new logical control mechanisms | |
| 154 | |
| 155 - switch all code over from using config vars for permission checks to using | |
| 156 permissions | |
| 157 | |
| 158 The command-line tool must be changed to: | |
| 159 | |
| 160 - use the new logical control mechanisms (only allowing write | |
| 161 access by admin users, and read-only by everyone else) | |
| 162 | |
| 163 |