Bug 1257077 - "User is not authorized to perform this action" error after upgrade in development environment
"User is not authorized to perform this action" error after upgrade in develo...
Status: CLOSED NOTABUG
Product: oVirt
Classification: Community
Component: ovirt-engine-installer (Show other bugs)
3.6
Unspecified Unspecified
unspecified Severity unspecified
: m1
: 3.6.0
Assigned To: Martin Perina
Pavel Stehlik
infra
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-26 04:50 EDT by Martin Perina
Modified: 2016-02-10 14:35 EST (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-31 02:39:14 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
engine logs (311.38 KB, application/x-gzip)
2015-08-26 04:50 EDT, Martin Perina
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 45343 master MERGED setup: aaa: Preserve external_id of existing admin user Never
oVirt gerrit 45508 master MERGED Revert "setup: aaa: Preserve external_id of existing admin user" Never

  None (edit)
Description Martin Perina 2015-08-26 04:50:26 EDT
Created attachment 1067193 [details]
engine logs

Description of problem:

After upgrading engine installed in development environment you cannot login using admin@internal, following error appears: 

  User is not authorized to perform this action

The issue is that legacy internal provider doesn't properly detect extenal_id of already existing admin users and creates a new one. So during login the admin user with new extenal_id is inserted into users table, but it doesn't have proper privileges.

Version-Release number of selected component (if applicable):

oVirt engine 3.6 and master

How reproducible:

100%

Steps to Reproduce:
1. Install engine into development environment and execute engine setup
2. Try to login as admin@internal -> works fine
3. Execute engine-setup using answer file generated from previous engine-setup execution
4. Try to login as admin@internal -> error

Actual results:

After upgrade (2nd engine-setup execution) error appears: User is not authorized to perform this action

Expected results:

Upgrade shouldn't affect admin@internal ability to login 

Additional info:
Comment 1 Alon Bar-Lev 2015-08-29 12:19:39 EDT
this is in post install file, please explain more about the fix.

    @osetupattrs(
        postinstallfile=True,
    )
    def ADMIN_USER_ID(self):
        return 'OVESETUP_CONFIG/adminUserId'
Comment 2 Martin Perina 2015-08-31 01:35:44 EDT
(In reply to Alon Bar-Lev from comment #1)
> this is in post install file, please explain more about the fix.
> 
>     @osetupattrs(
>         postinstallfile=True,
>     )
>     def ADMIN_USER_ID(self):
>         return 'OVESETUP_CONFIG/adminUserId'

Not sure what is the purpose of post install file, but you can try reproducing steps for yourself. Without patch 45343 new UUID is always assigned to admin@internal on every execution of engine-setup with answer file, but correct permissions are set only for the 1st admin@internal record.
Comment 3 Alon Bar-Lev 2015-08-31 01:38:38 EDT
(In reply to Martin Perina from comment #2)
> (In reply to Alon Bar-Lev from comment #1)
> > this is in post install file, please explain more about the fix.
> > 
> >     @osetupattrs(
> >         postinstallfile=True,
> >     )
> >     def ADMIN_USER_ID(self):
> >         return 'OVESETUP_CONFIG/adminUserId'
> 
> Not sure what is the purpose of post install file, but you can try
> reproducing steps for yourself. Without patch 45343 new UUID is always
> assigned to admin@internal on every execution of engine-setup with answer
> file, but correct permissions are set only for the 1st admin@internal record.

the role of post install file is to store values to be available at next setup run.
Comment 4 Alon Bar-Lev 2015-08-31 02:10:44 EDT
Tested again (of course tested in the past as I always upgrade) also most people upgrade and did not experience this.

Post install mechanism kicks in, user id is preserved.

Problem is different, wrong solution and complex one should be reverted.

What do you exactly call upgrade?

Only way I can see an issue is if you use existing database with empty environment, this also effects the jdbc provider.
Comment 5 Martin Perina 2015-08-31 02:20:14 EDT
(In reply to Alon Bar-Lev from comment #4)
> Tested again (of course tested in the past as I always upgrade) also most
> people upgrade and did not experience this.

I already have 3 developers including myself which are affected

> 
> Post install mechanism kicks in, user id is preserved.
> 
> Problem is different, wrong solution and complex one should be reverted.
> 
> What do you exactly call upgrade?
> 
> Only way I can see an issue is if you use existing database with empty
> environment, this also effects the jdbc provider.

So once again here are reproducing steps:

1. Install engine into $PREFIX
2. Execute engine-setup
3. Start engine and verify it works fine
4. Execute engine-setup again with answer file generated in step 2
5. Start engine -> you won't be able to login

You can rebase and rebuild engine between steps 3. and 4. (as this is what most developers do between engine-setup execution), but the result is the same
Comment 6 Alon Bar-Lev 2015-08-31 02:21:42 EDT
setup answer file should not feed into upgrade! only for new install.
Comment 7 Martin Perina 2015-08-31 02:28:41 EDT
That's how developers are using the answer file, nobody want's to enter anything manually during install/upgrades (not to mention that you need to bypass 'Setup was run under unprivileged user ...' answer by redirecting stdin

So what's you proposed solution for that?
Comment 8 Alon Bar-Lev 2015-08-31 02:31:08 EDT
(In reply to Martin Perina from comment #7)
> That's how developers are using the answer file, nobody want's to enter
> anything manually during install/upgrades (not to mention that you need to
> bypass 'Setup was run under unprivileged user ...' answer by redirecting
> stdin
> 
> So what's you proposed solution for that?

use setup as intended, the above is completely invalid statement.

there are two enters when upgrading setup, if it that difficult to press two enters set only these two.
Comment 9 Martin Perina 2015-08-31 02:39:14 EDT
(In reply to Alon Bar-Lev from comment #8)
> (In reply to Martin Perina from comment #7)
> > That's how developers are using the answer file, nobody want's to enter
> > anything manually during install/upgrades (not to mention that you need to
> > bypass 'Setup was run under unprivileged user ...' answer by redirecting
> > stdin
> > 
> > So what's you proposed solution for that?
> 
> use setup as intended, the above is completely invalid statement.

It would be OK, if there's a note somewhere that answer file can be used for new installations only. But I haven't found it anywhere

> 
> there are two enters when upgrading setup, if it that difficult to press two
> enters set only these two.
Comment 10 Alon Bar-Lev 2015-08-31 02:41:26 EDT
answer file is generated as answer to questions and other settings.

in setup there is one set of questions.
in upgrade there is another.

you cannot use answers of one into the other as different sets of "answers".

Note You need to log in before you can comment on or make changes to this bug.