When upgrading, "Install/Upgrade" privilege may have been previously lost

[gloomytrousers]

Raising this from https://bugzilla.redhat.com/show_bug.cgi?id=1670725

On Fedora 29, having upgraded from 1.2.0 to 1.2.1, after logging in (as "admin") I am presented with a screen:

There is an Installation or Upgrade in progress.

Only Cacti Administrators with Install/Upgrade privilege may login at this time

[Return | Login Again]

I cannot see any way past this screen to do the normal upgrade wizard.

This turned out to be because my user didn't have the "Installation/Upgrades" permission set. I was unable to correct this via the UI as I could not get past the upgrade screens, so in the end I downgraded to the previous version, granted the permission, and upgraded again.

This user has always been able to perform upgrades until now, and to the best of my knowledge I would never have explicitly disabled this permission. I am guessing this is a new-ish permission, which was not granted to existing users, and perhaps only enforced in an even more recent version. Whatever the cause, I think it's a poor user experience if upgrading from one version to the next causes the application to become inaccessible, and 'no users have permission to perform an upgrade' should be a condition that is detected and worked around in some way.

[netniV]

I would agree that the system shouldn't lock out all users but additionally, no all users should be performing the upgrade.

Starting with 1.2, the first person to login after the source has been updated will get granted the rights to Realm 26 which is the Install/Upgrade permission. The first person is normally the main administrator since they are the one doing the upgrade.

Running the following query in MySQL should show the user(s) who have this permission:

select id, realm_id, username from user_auth_realm uar inner join user_auth ua on ua.id = uar.user_id where realm_id = 26;
+----+----------+----------+
| id | realm_id | username |
+----+----------+----------+
|  1 |       26 | admin    |
|  7 |       26 | mark     |
+----+----------+----------+

This permission is visible within the users permission section (Console -> Configuration -> Users -> (Edit a user) -> Permissions):

If you look at include/auth.php and search for $realm == 26, you will see there is a section of code that runs through when upgrading from pre-1.2 to ensure that a user does have the upgrade rights and if not, assigns the currently logging in user with that right.

What this doesn't do is prevent an admin from removing all upgrade rights, which is potentially a bug.

[netniV]

Another thing you could try for me, remove the version check that I just noticed is on the $realm_id == 26 if check so that it reads as such:

--- a/include/auth.php
+++ b/include/auth.php
@@ -104,7 +104,7 @@ if (read_config_option('auth_method') != 0) {
                }
 
                /* Are we upgrading from a version before 1.2 which has the Install/Upgrade realm 26 */
-               if ($realm_id == 26 && cacti_version_compare(get_cacti_version(), '1.2', '<')) {
+               if ($realm_id == 26) {
                        /* See if we can find any users that are allowed to upgrade */
                        $install_sql_query = '
                                        SELECT COUNT(*)

[netniV]

Additionally, our Cacti.sql file does include the following statement which would give the access to the admin user for any new installations.

INSERT INTO user_auth_realm VALUES (26,1);

[cigamit]

Have we gotten to the bottom of this one?

[netniV]

Waiting to hear from @gloomytrousers

[gloomytrousers]

Sorry, didn't realise you were waiting on me. As per the description, I managed to get past the problem by downgrading, adding the permission then upgrading again, so I'm not really in a position to test any more.

[netniV]

Sorry, I missed that you'd gone back down to go back up. So when you went back up from 1.1.38, the second time it added the permission or you were able to add it because you were running 1.2 and edited the user?

[netniV]

@mortenstevens, are you able to test if it's a reoccurring issue or a one-off?

[gloomytrousers]

The latter - I downgraded from 1.2.1 to 1.2.0, edited the user, and upgraded again.

[netniV]

OK, so that's pretty much like running the insert that I suggested. I am curious why you didn't get the privilege as that code was heavily tested.

[netniV]

I'm looking at a database that a user had upgraded from 0.8.8 and that apparently has the privilege as I'd expect. So, there must be some corner case that is causing the issue but it only appears to be with the fedora package at the moment.

[mortenstevens]

@netniV
That should not be a Fedora specific issue, because we are shipping a "vanilla" cacti package as RPM without any patches. See: https://src.fedoraproject.org/rpms/cacti

I'm not sure about the best way to reproduce it. Anyway, you should be able to reproduce it on every cacti installation.

[cigamit]

Sorry, I updated the wrong ticket. 🥇 Hey look at that, I won a badge.

[cigamit]

The problem here is that someone unwittingly can remove themselves from having this permission. It should not be able to be un selected at least from the primary admin account. If no account has the permission the current user get's it by default. That way the system is fool-proof (mostly anyway).

[netniV]

The easier fix at the minute is to simply remove the version check that allows us to re-apply the permission to anyone who has the Utilities/Settings privilege already if no users have it.

[cigamit]

Or console access for that matter. Console access generally means an administrator.

[david-hill]

I hit the issue and fixed it using this:

MariaDB [cacti]> select id, realm_id, username from user_auth_realm uar inner join user_auth ua on ua.id = uar.user_id where realm_id = 26;
Empty set (0.001 sec)

MariaDB [cacti]> insert into user_auth_realm values (26,1);
Query OK, 1 row affected (0.035 sec)

[netniV]

OK. In that case, I will implement the workaround in our upgrade code so that this doesn't affect future releases.