Mercurial > p > roundup > code
annotate doc/security.txt @ 6814:3f60a71b0812
Summary: Support selecion session/otk data store. Add redis as data store.
Allow admin to select the backend data store. Compatibility matrix:
main\/ session>| anydbm | sqlite | redis | mysql | postgresql |
anydbm | D | | X | | |
sqlite | X | D | X | | |
mysql | | | | D | |
postgresql | | | | | D |
--------------------------------------------------------------+
D - default if unconfigured, X - compatible choice
DETAILS
roundup/configuration.py:
add config.ini section sessiondb with settings: backend and redis_url.
CHANGES.txt, doc/admin_guide.txt, doc/installation.txt, doc/upgrading.txt:
doc on config of session db and redis. Plus some other fixes:
admin - clarified why we do not drop __words and __testids
table in native-fts conversion. TYpo fix.
upgrading - doc how you can keep using anydbm for session data with
sqlite. Fix dupe sentence in an upgrading config.ini
section.
roundup/backends/back_anydbm.py, roundup/backends/back_sqlite.py:
code to support redis, redis/anydbm backends respectively.
roundup/backends/sessions_redis.py
new storage backend for redis.
roundup/rest.py, roundup/cgi/actions.py, roundup/cgi/templating.py
redis uses a different way of calculating lifetime/timestamp.
Since expiration of an item occurred if its timestamp was more
than 1 week old, code would calculate:
now - 1 week + lifetime.
But this results in faster expiration in redis if used for
lifetime/timestamp.
Convert code to use the lifetime() method in BasicDatabase
that generates the right timestamp for each backend.
test/session_common.py:
added tests for more cases, get without default, getall non-existing
key etc. timestamp test changed to use new self.get_ts which is
overridden in other tests. Test that datatypes survive storage.
test/test_redis_session.py:
test redis session store with sqlite and anydbm primary databases
test/test_anydbm.py, test/test_sqlite.py
add test to make sure the databases are properly set up
sqlite - add test cases where anydbm is used as datastore
anydbm - remove updateTimestamp override add get_ts().
test/test_config.py
tests on redis_url and compatibility on choice of sessiondb backend
.travis.yml:
add redis db and redis-py
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Thu, 04 Aug 2022 14:41:58 -0400 |
| parents | 8ee41c7372e7 |
| children | ffe29ee47c47 |
| rev | line source |
|---|---|
| 3940 | 1 =================== |
| 2 Security Mechanisms | |
| 3 =================== | |
| 4 | |
| 5 Current situation | |
| 6 ================= | |
| 7 | |
| 8 Current logical controls: | |
| 9 | |
| 10 ANONYMOUS_ACCESS = 'deny' | |
| 11 Deny or allow anonymous access to the web interface | |
| 12 ANONYMOUS_REGISTER = 'deny' | |
| 13 Deny or allow anonymous users to register through the web interface | |
| 14 ANONYMOUS_REGISTER_MAIL = 'deny' | |
| 15 Deny or allow anonymous users to register through the mail interface | |
| 16 | |
| 17 Current user interface authentication and controls: | |
| 18 | |
| 19 - command-line tool access controlled with passwords, but no logical controls | |
| 20 - CGI access is by username and password and has some logical controls | |
| 21 - mailgw access is through identification using sender email address, with | |
| 22 limited functionality available | |
| 23 | |
| 24 The web interface implements has specific logical controls, | |
| 25 preventing non-admin users from accessing: | |
| 26 | |
| 27 - other user's details pages | |
| 28 - listing the base classes (not issues or their user page) | |
| 29 - editing base classes | |
| 30 | |
| 31 Issues | |
| 32 ====== | |
| 33 | |
|
4732
8ee41c7372e7
doc: Fix some Sphinx warnings.
anatoly techtonik <techtonik@gmail.com>
parents:
4567
diff
changeset
|
34 1. The current implementation is ad-hoc, and not complete for all use cases. |
| 3940 | 35 2. Currently it is not possible to allow submission of issues through email |
| 36 but restrict those users from accessing the web interface. | |
| 37 3. Only one user may perform admin functions. | |
| 38 4. There is no verification of users in the mail gateway by any means other | |
| 39 than the From address. Support for strong identification through digital | |
| 40 signatures should be added. | |
| 41 5. The command-line tool has no logical controls. | |
| 42 6. The anonymous control needs revising - there should only be one way to be | |
| 43 an anonymous user, not two (currently there is user==None and | |
| 44 user=='anonymous'). | |
| 45 | |
| 46 | |
| 47 Possible approaches | |
| 48 =================== | |
| 49 | |
| 50 Security controls in Roundup could be approached in three ways: | |
| 51 | |
| 52 1) at the hyperdb level, with read/write/modify permissions on classes, items | |
| 53 and item properties for all or specific transitions. | |
| 54 2) at the user interface level, with access permissions on CGI interface | |
| 55 methods, mailgw methods, roundup-admin methods, and so on. | |
| 56 3) at a logical permission level, checked as needed. | |
| 57 | |
| 58 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
|
59 hyperdatabase itself, through operating-system controls such as user or group |
| 3940 | 60 permissions. |
| 61 | |
| 62 | |
| 63 Hyperdb-level control | |
| 64 --------------------- | |
| 65 | |
| 66 Control is implemented at the Class.get, Class.set and Class.create level. All | |
| 67 other methods must access items through these methods. Since all accesses go | |
| 68 through the database, we can implement deny by default. | |
| 69 | |
| 70 Pros: | |
| 71 | |
| 72 - easier to implement as it only affects one module | |
| 73 - smaller number of permissions to worry about | |
| 74 | |
| 75 Cons: | |
| 76 | |
| 77 - harder to determine the relationship between user interaction and hyperdb | |
| 78 permission. | |
| 79 - a lot of work to define | |
| 80 - must special-case to handle by-item permissions (editing user details, | |
| 81 having private messages) | |
| 82 | |
| 83 | |
| 84 User-interface control | |
| 85 ---------------------- | |
| 86 | |
| 87 The user interfaces would have an extra layer between that which | |
| 88 parses the request to determine action and the action method. This layer | |
| 89 controls access. Since it is possible to require methods be registered | |
| 90 with the security mechanisms to be accessed by the user, deny by default | |
| 91 is possible. | |
| 92 | |
| 93 Pros: | |
| 94 | |
| 95 - much more obvious at the user level what the controls are | |
| 96 | |
| 97 Cons: | |
| 98 | |
| 99 - much more work to implement | |
| 100 - most user interfaces have multiple uses which can't be covered by a | |
| 101 single permission | |
| 102 | |
| 103 Logical control | |
| 104 --------------- | |
| 105 | |
| 106 At each point that requires an action to be performed, the security mechanisms | |
| 107 are asked if the current user has permission. Since code must call the | |
| 108 check function to raise a denial, there is no possibility to have automatic | |
| 109 default of deny in this situation. | |
| 110 | |
| 111 Pros: | |
| 112 | |
| 113 - quite obvious what is going on | |
| 114 - is very similar to the current system | |
| 115 | |
| 116 Cons: | |
| 117 | |
| 118 - large number of possible permissions that may be defined, possibly | |
| 119 mirroring actual user interface controls. | |
| 120 - access to the hyperdb must be strictly controlled through program code | |
| 121 that implements the logical controls. | |
| 122 | |
| 123 | |
| 124 Action | |
| 125 ====== | |
| 126 | |
| 127 The CGI interface must be changed to: | |
| 128 | |
| 129 - authenticate over a secure connection | |
| 130 - use unique tokens as a result of authentication, rather than pass the user's | |
| 131 real credentials (username/password) around for each request (this means | |
| 132 sessions and hence a session database) | |
| 133 - use the new logical control mechanisms | |
| 134 | |
| 135 - implement the permission module | |
| 136 - implement a Role editing interface for users | |
| 137 - implement htmltemplate tests on permissions | |
| 138 - switch all code over from using config vars for permission checks to using | |
| 139 permissions | |
| 140 - change all explicit admin user checks for Role checks | |
| 141 - include config vars for initial Roles for anonymous web, new web and new | |
| 142 email users | |
| 143 | |
| 144 The mail gateway must be changed to: | |
| 145 | |
| 146 - use digital signatures | |
| 147 - use the new logical control mechanisms | |
| 148 | |
| 149 - switch all code over from using config vars for permission checks to using | |
| 150 permissions | |
| 151 | |
| 152 The command-line tool must be changed to: | |
| 153 | |
| 154 - use the new logical control mechanisms (only allowing write | |
| 155 access by admin users, and read-only by everyone else) | |
| 156 | |
| 157 |