This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 806001 - aeolus-configure will always create an admin user, need to key of a uuid not name
aeolus-configure will always create an admin user, need to key of a uuid not ...
Status: CLOSED ERRATA
Product: CloudForms Cloud Engine
Classification: Red Hat
Component: aeolus-configure (Show other bugs)
1.0.0
Unspecified Unspecified
unspecified Severity high
: rc
: ---
Assigned To: Steve Linabery
wes hayutin
: ZStream
Depends On:
Blocks: 824526
  Show dependency treegraph
 
Reported: 2012-03-22 12:17 EDT by wes hayutin
Modified: 2012-12-04 10:00 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Previously, aeolus-configure created an admin user even if one already existed. This bug fix updates dc_tasks.rake so that admin/password account is created only once on running aeolus-configure.
Story Points: ---
Clone Of:
: 824526 (view as bug list)
Environment:
Last Closed: 2012-12-04 10:00:46 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description wes hayutin 2012-03-22 12:17:53 EDT
Description of problem:

aeolus-configure will always create an admin user even one has already been created.

Scenario..
1. user runs aeolus-configure, hates the username=admin and changes the username  to "root" and changes the password
2. user runs aeolus-configure again .. whoops.. admin/password is created and is a bit of a security hole


ideally.. the original admin user should have some sort of uuid of 0, and aeolus-configure always uses that id to configure resources.

So.. user can change the username/pass of "admin" to anything and that user is still the only admin on the box after aeolus-configure is executed
Comment 1 Scott Seago 2012-03-22 12:58:16 EDT
There's no restriction on the number of admins -- an admin isn't  a special kind of user. Rather an admin is a user who happens to have been given the "Administrator" global role. In fact, in the UI an admin can assign full admin rights to any number of other real users.

However, the current situation is still problematic. We could do a couple things:
1) make 'admin creation' optional in -configure
2) only create an admin user if there aren't currently any users with admin rights -- i.e. run a query and if there's already one or more users with the global 'Administrator' role  defined, don't add another.

I think in reality, for any installation that uses ldap users we won't want to use the non-ldap 'admin' user anyway -- we'd want the admins to be regular users with their ldap logins that have been granted 'admin' rights.
Comment 3 Hugh Brock 2012-05-11 10:28:08 EDT
Option 2 seems the nicest. Steve, how hard is this to fix? We are considering it for z-stream.
Comment 4 Steve Linabery 2012-05-16 14:21:19 EDT
I would like to make admin creation a separate, optional profile. User would need to invoke 'aeolus-configure -p create_admin_user' to have a 'default' user set up. The profile would include login/password as optional parameters with defaults of 'admin'/'password'.

If a user with login 'admin' (or whatever the value of the 'login' parameter in the profile is) exists, do nothing.

I discovered a more substantial problem while considering implementing the above approach.

In several places in our puppet manifests, we use web requests that require valid administrator-level, plain-text login/password information. For example, when we set up ec2 providers in class aeolus::profiles::ec2.

In the presumably typical case where user has retained the login 'admin' but changed the password, we can't extract the plain-text password from the rdbms. Obviously this applies to any other pre-existing un/pw that user has created and is using in an administrative capacity.

I suggest we create, at the start of each puppet run, a temporary user which is granted administrative rights, do whatever configuration work is needed using the temp-user's credentials, and destroy the temp-user at the end of each run.

temp-user login names would follow a set pattern, e.g. 'temp-admin-user-%d%d%d', and we could delete all users that match the pattern prior to creation of a new temp-user. This handles the case where something goes wrong with a puppet run and a 'stale' temp-user is left over.

In any case, we would set the password to a secure random string to prevent access via the temp-user.

rwsu and sseago raised the issue of possibly orphaning objects created during puppet runs. I logged the sql statements of a sample run of aeolus-configure using the default profile, and found no objects created that required a user owner. However, this might affect future enhancements to -configure, for example if we created a profile that created an instance. For the time being, the temp-user approach strikes me as the least disruptive way to address this BZ.

Comments encouraged.
Comment 5 Dave Johnson 2012-05-16 16:26:30 EDT
I lean towards option 1 being the better option from the point of 'admin user recovery'.  If you don't have passwords to other user accounts who have admin rights with option 2, there is no way to recover a admin user.  And what if those other users are all 'inactive'?

I like what Steve proposes allow I think it could still be problematic it terms of what Wes's describes.  Users might not necessarily know the implications and still accidently create a 'extra' default admin user???  I am wondering if login/password parameters should be required and perhaps if it exists, the password gets reset.

In terms of the temporary user creating system level objects that only require admin rights, no objections come to mind.  In the scenario of objects requiring a user owner, I would think you would need to specify credentials, which are then passed through permissions to create the desired object.
Comment 6 Steve Linabery 2012-05-22 17:46:38 EDT
1a46ebbfde98f9d86498547e50f312b13aa0b49e on conductor master branch.
9bffb2ce99394ee9231734d9830d2977469155d0 on aeolus-configure master branch.
Comment 9 Shveta 2012-09-28 17:49:18 EDT
admin/password account is created only once on running aeolus-configure.


Tests :

1) Run aeolus-configure , admin/password is created.
2) Run aeolus-configure again , admin is not created again
3) Change the username of admin to something else (admin123) and run aeolus-configure again, admin is not created


=============================================

rpm -qa|grep aeolus
rubygem-aeolus-image-0.3.0-12.el6.noarch
rubygem-aeolus-cli-0.7.2-1.el6cf.noarch
aeolus-conductor-doc-0.13.14-1.el6cf.noarch
aeolus-all-0.13.14-1.el6cf.noarch
aeolus-conductor-0.13.14-1.el6cf.noarch
aeolus-configure-2.8.7-1.el6cf.noarch
aeolus-conductor-daemons-0.13.14-1.el6cf.noarch
Comment 11 errata-xmlrpc 2012-12-04 10:00:46 EST
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

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

http://rhn.redhat.com/errata/RHEA-2012-1516.html

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