Bug 1656794

Summary: Disable the ability to remove permissions to Everyone
Product: [oVirt] ovirt-engine Reporter: Paul Staniforth <p.staniforth>
Component: Frontend.WebAdminAssignee: Dana <delfassy>
Status: CLOSED CURRENTRELEASE QA Contact: Roni <reliezer>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 4.2.7.1CC: bugs, lleistne, mperina, reliezer, rnori, robert.suszek96, saksham.sa.srivastava, sborella, vpagar
Target Milestone: ovirt-4.3.2Flags: rule-engine: ovirt-4.3+
lleistne: testing_ack+
Target Release: ---   
Hardware: All   
OS: Unspecified   
Whiteboard: VerificationWeek
Fixed In Version: ovirt-engine-4.3.2 Doc Type: Enhancement
Doc Text:
This release disables the "Remove" button on the Everyone permissions page to prevent misconfiguring Red Hat Virtualization Manager permissions.
Story Points: ---
Clone Of: Environment:
Last Closed: 2019-03-19 10:05:20 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Infra RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Paul Staniforth 2018-12-06 10:51:13 UTC
Description of problem:
In Administration->Users->Everyone can add system permissions

When you try to remove the permission the operation is cancelled with the message

Error while executing action: It's not allowed to remove system permissions assigned to built-in Everyone group

Version-Release number of selected component (if applicable):
4.2 up to the latest version 4.2.7.1

How reproducible:
Always

Steps to Reproduce:
1. add  system permission to group everyone
2. remove same permission


Actual results:
Can't remove permission

Expected results:
Either don't allow system permission to be added or allow it to be removed

Additional info:

It looks like the only way to remove the permission is to delete it from the engine database

Comment 1 Martin Perina 2019-01-21 14:34:01 UTC
We have disable the ability to remove permissions from Eveyrone, because administrators performed too many mistakes, which ended in unrecoverable corrupted engine permissions. So it makes sense also to disable adding permissions to Everyone to prevent confusion.

If administrators wants to assign permissions to all users, then it makes sense to create a group, where all users belongs, and assign a relevant system permission to this group.

Comment 2 Robert Suszek 2019-01-31 11:01:08 UTC
By mistake I have added a VnicProfileUser to Everyone which I don't want, is there any way, other than modifying the database, to delete it? I wouldn't want to alter the database in any way manually.

Comment 3 Ravi Nori 2019-01-31 18:30:00 UTC
Base on comment #1 updating the title of the BZ. The remove permissions button should be disabled on the Everyone permissions page.

Leaving the ability to add permissions for Everyone so as to avoid breaking any customer user cases

Comment 4 Roni 2019-03-06 15:36:15 UTC
Verified: 4.3.2-0.1.el7

Comment 5 Sandro Bonazzola 2019-03-19 10:05:20 UTC
This bugzilla is included in oVirt 4.3.2 release, published on March 19th 2019.

Since the problem described in this bug report should be
resolved in oVirt 4.3.2 release, it has been closed with a resolution of CURRENT RELEASE.

If the solution does not work for you, please open a new bug report.

Comment 6 Saksham-oracle 2023-05-18 15:32:39 UTC
"Leaving the ability to add permissions for Everyone so as to avoid breaking any customer user cases"

For exactly what user case breaking, we have not disabled the add option for "Everyone" group. If a user wants to give extra permission to all users, they can create a group with desired permissions and add all the users to the group. By keeping the add permission option and disabling the remove option, we are asking customers to remove permission(if added by mistake) by following the database route. If we are not allowing removing permission, why are we allowing to add permission?

(In reply to Ravi Nori from comment #3)
> Leaving the ability to add permissions for Everyone so as to avoid breaking
> any customer user cases