Merge pull request #1140 from whisperity/superuser-in-unauth-mode

Give everyone SUPERUSER permission if authentication is not enabled

docs/permissions.md

@@ -63,16 +63,16 @@ will automatically **have the `SUPERUSER` permission**.
  * Product-level permissions can be edited by clicking the edit icon for the
    product you want to configure the permissions for.
 
-Permissions can be managed on the web interface. From the dropdown, select the
+Permissions can be managed on the web interface. From the drop-down, select the
 permission you want to configure. The two lists show the users and groups
 known to the system - if a tick is present in its row, the given user or group
 has the permission directly granted. (Users who only have a certain permission
 through permission inheritance are not shown with a tick.)
 
-Only the permissions you have rights to manage are shown in the dropdown.
+Only the permissions you have rights to manage are shown in the drop-down.
 
 You can edit multiple permissions opening the window only once. Simply tick or
-untick the users/groups you want to give the permission to or revoke from them.
+un-tick the users/groups you want to give the permission to or revoke from them.
 Clicking *OK* will save the changes to the database.
 
 ## <a name="permission-concepts"></a> Permission concepts
@@ -81,19 +81,20 @@ Each permission has a unique name, such as `SUPERUSER` or `PRODUCT_ADMIN`.
 
 ### <a name="default-value"></a> Default value
 
-Permissions can either be *not granted* or *granted* by default. 
+Permissions can either be *not granted* or *granted* by default.
 
 Some permissions are *default not granted*, which means that only users whom
-are explicitly given the permission have it. This also means that if the
-server is running with authentication disabled, no one has the permission
-granted.
+are explicitly given the permission have it.
 
 Some permissions are *default granted*, which means that initially, every user
-(this includes guests if the server is running with authentication disabled)
 has the permission. However, if at least one user or group is explicitly
 given the permission, only the users who have the permission given will be
 able to utilise it.
 
+If the server is running without authentication &ndash; in this case there are
+no "users" as everyone is a guest &ndash; **every permission is automatically
+granted**.
+
 ### <a name="permission-inheritance"></a> Permission inheritance
 
 Certain permissions automatically imply other permissions, e.g. a

docs/postgresql_setup.md

@@ -69,7 +69,7 @@ chmod 0600 ~/.pgpass
 > For format and further information on `pgpass` files, please refer to the
 > [PostgreSQL documentation](http://www.postgresql.org/docs/current/static/libpq-pgpass.html).
 
-At this point, you can normall continue with installing the neccessary Python
+At this point, you can normal continue with installing the necessary Python
 requirements and creating an install of CodeChecker:
 
 ~~~~~~{.sh}

docs/products.md

@@ -57,15 +57,7 @@ product configuration. All these commands take a server URL (e.g.
 and not an individual product endpoint.
 
 Certain administrative actions regarding products can only be executed by
-[superusers](/docs/permissions.md). If you are running a server without
-[authentication](/docs/authentication.md) turned on, no access to these
-features is the expected behaviour. You can use the combination of
-[`--force-authentication` and `--reset-root`
-commands](/docs/user_guide.md#master-superuser-and-authentication-forcing) to
-restart your server specifically to can access administrative actions. When
-the server is started as such, use [`CodeChecker cmd
-login`](/docs/user_guide.md#authenticate-to-the-server-login) to authenticate
-yourself with the "root" credentials generated for this running server.
+[superusers](/docs/permissions.md), if the server has authentication turned on.
 
 ~~~~~~~~~~~~~~~~~~~~~
 usage: CodeChecker cmd products [-h] [--verbose {info,debug,debug_analyzer}]
@@ -198,14 +190,8 @@ optional arguments:
 # <a name="web-interface"></a> Managing products through the web interface
 
 Certain administrative actions regarding products can only be executed by
-[superusers](/docs/permissions.md). If you are running a server without
-[authentication](/docs/authentication.md) turned on, no access to these
-features is the expected behaviour. You can use the combination of
-[`--force-authentication` and `--reset-root`
-commands](/docs/user_guide.md#master-superuser-and-authentication-forcing) to
-restart your server specifically to can access administrative actions. When
-the server is started as such and the browser prompts for authentication,
-enter the generated "root" credentials.
+[superusers](/docs/permissions.md) if the server is running with authentication
+turned on.
 
 !["Add new product" dialog](/docs/images/newproduct.png)
 

libcodechecker/server/permissions.py

@@ -37,7 +37,8 @@ def __init__(self, name, default_enable=True,
         :param name:           The name of the permission
         :param default_enable: If False, only the people explicitly given this
           permission are marked as having it. If True, an empty list of people
-          given the permission means that everyone has the permission.
+          given the permission means that everyone has the permission, if the
+          server is running in authentication ENABLED mode.
         :param inherited_from: The list of permissions which automatically
           imply this permission. (Disjunctive list, i.e. if the user has
           either of these permissions specified, they have the current one
@@ -204,8 +205,11 @@ def has_permission(self, auth_session):
         the current permission.
         """
         if not auth_session:
-            return self._permission.default_enable
-        if auth_session.is_root and self._perm_name == 'SUPERUSER':
+            # If the user does not have an auth_session it means it is a guest
+            # and the server is running in authentication disabled mode.
+            # All permissions are automatically granted in this case.
+            return True
+        elif auth_session.is_root and self._perm_name == 'SUPERUSER':
             # The special master superuser (root) automatically has the
             # SUPERUSER permission.
             return True
@@ -214,7 +218,7 @@ def has_permission(self, auth_session):
         groups = self._has_perm_impl(auth_session.groups, True)
 
         if not name and not groups and self._permission.default_enable:
-            # Default enabled permission work in a way that if noone has the
+            # Default enabled permission work in a way that if no one has the
             # permission, everyone has it.
             # ("No-one has the permission" is represented as a * user having
             # the permission, this invariant kept up by add() and remove().)
@@ -224,7 +228,7 @@ def has_permission(self, auth_session):
 
     def list_permitted(self):
         """
-        Returns the a pair of usernames and groups that are given the current
+        Returns a pair of usernames and groups that are given the current
         permission.
         """
         records = self._list_authorised_impl()
@@ -446,6 +450,7 @@ def __call__(self, config_db_session, productID):
 
 # ---------------------------------------------------------------------------
 
+
 PERMISSION_SCOPES = {
     'SYSTEM': SystemPermission,
     'PRODUCT': ProductPermission