RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1081286 - [RFE] Cannot add unencrypted administrative credentials of Vcenter in "/etc/sysconfig/virt-who"
Summary: [RFE] Cannot add unencrypted administrative credentials of Vcenter in "/etc/s...
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: virt-who
Version: 6.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Radek Novacek
QA Contact: gaoshang
Depends On:
TreeView+ depends on / blocked
Reported: 2014-03-27 01:40 UTC by Jayaram Alla
Modified: 2018-12-09 17:41 UTC (History)
11 users (show)

Fixed In Version: virt-who-0.10-1.el6
Doc Type: Enhancement
Doc Text:
Clone Of:
Last Closed: 2014-10-14 07:13:14 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 767913 0 None None None Never
Red Hat Product Errata RHBA-2014:1513 0 normal SHIPPED_LIVE virt-who bug fix and enhancement update 2014-10-14 01:22:23 UTC

Description Jayaram Alla 2014-03-27 01:40:02 UTC
Description of problem:
We have customers pointing that they cannot add the unencrypted administrative credentials in "/etc/sysconfig/virt-who".This is in thee case of registering the system using Virtual data center subscription.

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

How reproducible:

Actual results:
direct credentials of the administors need to be provided  virt-who config file which the customer is feeling risky.

Expected results:
There should be a provision of providing the credentials in encrypted form if possible. else should show any other way to provide the details.

Comment 1 Jayaram Alla 2014-03-27 01:48:32 UTC
I have 2 customers reported the above concern for whom i have advised to use RHN Classic as we dont have such functionality as of now. Please correct me if I am wrong and let me know if there is any alternate solution for this.

Below article may give you more idea 

 "Using RHEL subscriptions (2013 packaging): Scenario 5 - Virtual Datacenter "
  >> https://access.redhat.com/site/articles/480693

Comment 3 Jayaram Alla 2014-03-28 16:49:43 UTC
Here are some more requested inputs from the customer.

> - business justification i.e list the business requirements

Only admin servers/desktops have access to vCenter.
So Red Hat must provide a way to register RHEL guests on third party hypervisors without requiring VMs to have admin access to vCenter (the current girt-who stuff is just defective by design)
Registration/enrollement must be automatic (no need to go on the RedHat support website and assign enrolments for each an every VM)

> - do you have specific timeline dependencies?

No specific timeline dependencies.

> - would you be able to assist in testing this functionality if implemented?


Comment 5 Radek Novacek 2014-04-15 11:11:11 UTC
Hi, my current plan is following:

1) try to figure out, if virt-who could be used without administrator privileges on vCenter. Would it be OK for customer to have credentials for some non-admin user stored unencrypted in virt-who config file?

2) if not, add some possibility to encrypt the password that is supplied in the config file. I don't see any possibility how make the password storage secure but we can try to make it harder to read, but it will just be security through obscurity.

Comment 6 Yogendra Jog 2014-05-05 13:42:30 UTC
This is kind of roundrobbin.

CU's need to use virt-who to register the RHEL guest installed on VMware-ESX or Hyper-V.  CU cannot do that as their company security policy does not allow them to mention passwords in "clear text" in virt-who config which is an administrative user.  

Though I have seen another case where read only user may also work ? There is no alternate method to achieve this & customers are getting frustrated.  Case - 01066127 where customer has 5 QTY of SKU RH00002 Red Hat Enterprise Linux for Virtual Datacenters, Standard, which cannot be fully utilized because of this issue.


Comment 8 Radek Novacek 2014-05-19 12:06:34 UTC
So, is following solution acceptable for you:

Have some utility that will ask you for your password and will return encoded string. You will place this encoded string to virt-who config file.

On the background there will be file with the encryption key somewhere on the disk only accessible by root.

There is no added security in this approach, anyone with the root access will still be able to get your password, but the password won't be stored in plaintext in the configuration file.

Comment 10 Sal Castiglione 2014-05-30 15:19:28 UTC
That sounds like a better interim solution, than having the password saved as cleartext, along with having the permissions of the virt-who config file default to 600 instead of 644 ?

Also - I found another bug with the girt-who service:  If the password being used ends with an & character as the 3rd to last, the service fails as it’s being interpreted as a command.

For example, if the password is:  12345abcde&F1
when trying to start/stop the service, it will return
/etc/sysconfig/virt-who: line 44: F!: command not found


Comment 11 Radek Novacek 2014-06-02 06:34:12 UTC
Config file permissions will be changed to 600.

The behavior with ampersand in the password is expected. The /etc/sysconfig/virt-who file is read as a shell script that sets some environmental variables. The password should be quoted, e.g.


I'll add note that this could happen.

Thanks for noticing.

Comment 12 Radek Novacek 2014-06-06 12:08:25 UTC
This bug is fixed upstream and will be resolved by rebase of virt-who, see bug 1002640.

Comment 13 Radek Novacek 2014-06-18 07:34:03 UTC
This is already implemented, removing FutureFeature keyword.

Comment 14 Radek Novacek 2014-06-18 13:49:06 UTC
This bug is fixed by rebase to virt-who-0.10-1.el6.

Comment 16 Liushihui 2014-07-28 06:46:41 UTC
Verify it on virt-who-0.10-3.el6.noarch. 

Config file /etc/sysconfig/virt-who permissions has been modified to 600.
[root@hp-z220-05 sysconfig]# ls -alt virt-who 
-rw-------. 1 root root 1846 Jul 28 14:29 virt-who

Comment 17 Jayaram Alla 2014-08-28 18:21:08 UTC
Hello Radek,

May I know whether is there any date planned for the release of this fix ? so that I can update customer accordingly.

Thank you in advance.

Comment 18 Radek Novacek 2014-08-29 06:08:02 UTC
This will be part of RHEL-6.6 release that is currently planned to the mid of October.

Comment 20 errata-xmlrpc 2014-10-14 07:13:14 UTC
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.


Comment 21 Chris Roberts 2014-10-21 15:59:42 UTC

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