root-enable gives access to create unnnoticed root-like users

Bug #1472655 reported by Sushil Kumar on 2015-07-08
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack DBaaS (Trove)
Petr Malik

Bug Description

A security hole exists where a user can create an alternate root user, using following workflow

1. create an instance.
2. enable root
3. create another user manually after logging into database, and grant full access.
4. delete 'root'@'%' user.
5. backup the instance.
6. restore the backup to another instance, now this new instance has a root-access user without the knowledge of deployer.

Changed in trove:
assignee: nobody → Sushil Kumar (sushil-kumar2)
Changed in trove:
importance: Undecided → Critical
Changed in trove:
status: New → In Progress
Changed in trove:
milestone: none → liberty-2
Amrith Kumar (amrith) wrote :

I suggest you enter a BP for this

Sushil Kumar (sushil-kumar2) wrote :

With the fix I have proposed(, it seems to me a simple one liner.

Changed in trove:
importance: Critical → High
Changed in trove:
milestone: liberty-2 → liberty-3
Changed in trove:
milestone: liberty-3 → ongoing
Morgan Jones (6-morgan) wrote :

Doing a blueprint is more about the impact of the change and how many people should have the option to review the change, than it has to do with the number of lines of code changed. While I see the merit of this change, even if it is not the complete solution to the problem, I do believe a blueprint is warranted to increase the visibility of the change.

Craig Vyvial (cp16net) wrote :

I disagree with Morgan here because it is a bug in the code and not an additional feature.

Amrith Kumar (amrith) wrote :

What is the "bug" here?

You grant a person super-user access, then you can assume that the person will do things that are permissible with that superuser access.

The implication of 'root access' is that once granted, the instance is tainted. Once root access is granted to an instance, it is forever 'root enabled'.

Therefore to claim that this is a security hole is, first of all, not a meaningful assumption.

I requested a bp (in my review) and I believe that there is more to consider here than merely changing one query. That is akin to applying Johnson and Johnson's finest Band Aid on the side of the HMS Titanic.

Amrith Kumar (amrith) on 2016-04-05
Changed in trove:
milestone: ongoing → newton-1
assignee: Sushil Kumar (sushil-kumar2) → nobody
Amrith Kumar (amrith) on 2016-07-28
Changed in trove:
assignee: nobody → Petr Malik (pmalik)

Change abandoned by amrith (<email address hidden>) on branch: master
Reason: per trove meeting, August 10th, this is being abandoned for inactivity. If you want to continue work on this you can restore it.

Amrith Kumar (amrith) on 2016-09-18
Changed in trove:
milestone: newton-1 → ongoing
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers