Mercurial > p > roundup > code
annotate doc/security.txt @ 6915:9ff091537f43
postgresql native-fts; more indexer tests
1) Make postgresql native-fts actually work.
2) Add simple stopword filtering to sqlite native-fts indexer.
3) Add more tests for indexer_common get_indexer
Details:
1) roundup/backends/indexer_postgresql_fts.py:
ignore ValueError raised if we try to index a string with a null
character in it. This could happen due to an incorrect text/ mime
type on a file that has nulls in it.
Replace ValueError raised by postgresql with customized
IndexerQueryError if a search string has a null in it.
roundup/backends/rdbms_common.py:
Make postgresql native-fts work. When specified it was using using
whatever was returned from get_indexer(). However loading the
native-fts indexer backend failed because there was no connection to
the postgresql database when this call was made.
Simple solution, move the call after the open_connection call in
Database::__init__().
However the open_connection call creates the schema for the
database if it is not there. The schema builds tables for
indexer=native type indexing. As part of the build it looks at the
indexer to see the min/max size of the indexed tokens. No indexer
define, we get a crash.
So it's a a chicken/egg issue. I solved it by setting the indexer
to the Indexer from indexer_common which has the min/max token size
info. I also added a no-op save_indexer to this Indexer class. I
claim save_indexer() isn't needed as a commit() on the db does all
the saving required. Then after open_connection is called, I call
get_indexer to retrieve the correct indexer and
indexer_postgresql_fts woks since the conn connection property is
defined.
roundup/backends/indexer_common.py:
add save_index() method for indexer. It does nothing but is needed
in rdbms backends during schema initialization.
2) roundup/backends/indexer_sqlite_fts.py:
when this indexer is used, the indexer test in DBTest on the word
"the" fail. This is due to missing stopword filtering. Implement
basic stopword filtering for bare stopwords (like 'the') to make the
test pass. Note: this indexer is not currently automatically run by
the CI suite, it was found during manual testing. However there is a
FIXME to extract the indexer tests from DBTest and run it using this
backend.
roundup/configuration.py, roundup/doc/admin_guide.txt:
update doc on stopword use for sqlite native-fts.
test/db_test_base.py:
DBTest::testStringBinary creates a file with nulls in it. It was
breaking postgresql with native-fts indexer. Changed test to assign
mime type application/octet-stream that prevents it from being
processed by any text search indexer.
add test to exclude indexer searching in specific props. This code
path was untested before.
test/test_indexer.py:
add test to call find with no words. Untested code path.
add test to index and find a string with a null \x00 byte. it was
tested inadvertently by testStringBinary but this makes it explicit
and moves it to indexer testing. (one version each for: generic,
postgresql and mysql)
Renamed Get_IndexerAutoSelectTest to Get_IndexerTest and renamed
autoselect tests to include autoselect. Added tests for an invalid
indexer and using native-fts with anydbm (unsupported combo) to make
sure the code does something useful if the validation in
configuration.py is broken.
test/test_liveserver.py:
add test to load an issue
add test using text search (fts) to find the issue
add tests to find issue using postgresql native-fts
test/test_postgresql.py, test/test_sqlite.py:
added explanation on how to setup integration test using native-fts.
added code to clean up test environment if native-fts test is run.
| author | John Rouillard <rouilj@ieee.org> |
|---|---|
| date | Mon, 05 Sep 2022 16:25:20 -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 |
