1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
|
Deployment instructions
=======================
Currently deployment is supported on Ubuntu Lucid/Maverick with sqlite and
apache. Using other databases is likely to work but it was not tested for this
release.
Dashboard Requirements (debian package names, see setup.py meta-data for details and versions):
* python-django
* python-django-openid-auth
* python-docutils
* python-linaro-json
* python-linaro-dashboard-bundle
* python-django-pagination
For testing/packaging also install:
* python-django-testscenarios
Installation
============
See INSTALL
Reporting Bugs
==============
All bugs should be reported to the launchpad project at
https://bugs.launchpad.net/launch-control/+filebug
Known Issues
============
1. Django 1.1 present on Ubuntu 10.04.1 LTS and possibly other installations
suffers from a bug that prevents tests for django.contrib.auth to work
correctly. This issue is has been reported and is tracked inside Launchpad:
https://bugs.edge.launchpad.net/ubuntu/+source/python-django/+bug/650473
Securing data views
===================
Data views are essentially arbitrary SQL queries performed by the database
engine that are exposed to untrusted users. In all but extremely simple cases
data views should be sand-boxed at database level to prevent data leaks or data
loss.
Sand-boxing prevents the user invoking the query (as understood by the database
engine) from altering the data and constrains the tables and columns the user
can reference.
Currently this feature is only available when using PostgreSQL backend. To
enable it run the following set of queries as the database administrator.
We first have to create a role (user) that will be used for dataview queries.
The name of that user is derived from the name of the user owning the primary
connection suffixed with "_dataview". Here, since we are using default
deployment, the user is called "launchcontrol_dataview".
The user must have the same password as the primary user. You can reference
/etc/launch-control/default_database.conf for the value you are using.
launchcontrol=# CREATE ROLE launchcontrol_dataview WITH OPTION LOGIN, PASSWORD {password};
By default this new role has no permissions to do anything. We must explicitly
grant each right. We'll allow selecting data from two tables outside of the
dashboard. Content types are a part of Django implementation details and do
not contain any private data. The user table will allow queries to resolve user
primary key to a username.
launchcontrol=# GRANT SELECT (username, id) ON TABLE auth_user TO launchcontrol_dataview;
launchcontrol=# GRANT SELECT ON TABLE django_content_type TO launchcontrol_dataview;
This step is larger, we explicitly allow selecting data from all the dashboard
tables:
launchcontrol=# GRANT SELECT ON TABLE
dashboard_app_bundle,
dashboard_app_bundlestream,
dashboard_app_hardwaredevice,
dashboard_app_namedattribute,
dashboard_app_softwarepackage,
dashboard_app_softwaresource,
dashboard_app_test,
dashboard_app_testcase,
dashboard_app_testresult,
dashboard_app_testrun,
dashboard_app_testrun_devices,
dashboard_app_testrun_packages,
dashboard_app_testrun_sources
TO launchcontrol_dataview;
Finally we need to create or edit a small configuration file to make the
dashboard use the constrained role. Since we are using django-debian many
configuration variables traditionally configured via 'settings.py' can be
defined in /etc/launch-control/settings.conf. By default that file is not
created. You should create it and place following text inside:
{
"use_dataview_database": true
}
That's it. Now restart the application and check that your data views still
work.
|