Bug 548634 - Cannot use # character in dsn password field default_db in /etc/rhn/rhn.conf configuration file
Summary: Cannot use # character in dsn password field default_db in /etc/rhn/rhn.con...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server
Version: 530
Hardware: All
OS: Linux
low
medium
Target Milestone: ---
Assignee: Michael Mráka
QA Contact: Martin Minar
URL:
Whiteboard:
Depends On: 553004
Blocks: sat560-lowbug
TreeView+ depends on / blocked
 
Reported: 2009-12-18 00:40 UTC by Michael Kearey
Modified: 2018-11-27 21:50 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-10-01 21:52:33 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
rhnConf.py that handles quoted variables, and allows # characters in the variables within quotes. (26.62 KB, text/plain)
2009-12-18 00:56 UTC, Michael Kearey
no flags Details

Description Michael Kearey 2009-12-18 00:40:00 UTC
Description of problem:
A basic requirement to improve password quality is to be able to use non-alphanumeric characters, like '#' in a password. The parsing of /etc/rhn/rhn.conf cannot handle such characters, for example if the rhnsat user's database password is changed to :

myReal#secure

The database itself handles that just fine. The python code that parses the default_db config file entry in /etc/rhn/rhn.con like so:

default_db = rhnsat/myReal#secure@rhnsat

does not handle the # character. The other places here a DB password is defined also do not have the # character handled properly

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

How reproducible:
100%

Steps to Reproduce:
1. Install rhn Satellite 
2. Verify it is working


3. Stop the rhn-satellite
# rhn-satellite stop


4. Become oracle user, and make sure the DB is stopped:

# su - oracle -s /bin/bash
-bash-3.2$ db-control status
The database is offline.



5. Start the DB instance:
-bash-3.2$ db-control start
Starting database... done.



6. Connect to the oracle DB system:

-bash-3.2$ ORACLE_SID=rhnsat sqlplus system/rhnsat
..,
SQL>

7. Change the password for the rhnsat user:

SQL> alter user rhnsat identified by "rhnMySatellite3##wingnut" account unlock;

User altered.

SQL> quit
...,


7. Test connection using new password:

-bash-3.2$ sqlplus rhnsat/rhnMySatellite3##wingnut@rhnsat

...,
SQL> quit
...,


8. Stop the DB:

-bash-3.2$ db-control stop
Shutting down database... done.




9. Now edit the DB password in several places:

/etc/rhn/rhn.conf:default_db = rhnsat/rhnsat@rhnsat
/etc/rhn/rhn.conf:hibernate.connection.password=rhnsat
/etc/rhn/cluster.ini:LocalConfig.0.password=rhnsat

For example my new password is "rhnMySatellite3##wingnut" and I need to quote it now
because it has the # character in it:


/etc/rhn/rhn.conf:default_db = rhnsat/rhnMySatellite3##wingnut@rhnsat
/etc/rhn/rhn.conf:hibernate.connection.password=rhnMySatellite3##wingnut
/etc/rhn/cluster.ini:LocalConfig.0.password=rhnMySatellite3##wingnut


10. Start the Satellite 
  
Actual results:
Several services that need to connect to the Orace DB instance fail, and the rhnsat user is locked. The Satellite is non-functional.

Expected results:
Should be able to use # characters in passwords for the Oracle DB

Additional info:
I propose that we allow quotes around variables in /etc/rhn/rhn.conf, and change the rhnConf.py file parse_line function so it handles quotes, and thus allows # characters.

Comment 1 Michael Kearey 2009-12-18 00:56:47 UTC
Created attachment 379130 [details]
rhnConf.py that handles quoted variables, and allows # characters in the variables within quotes.

Altered rhnConf.py  so it handles quoted variables, and allows # characters in the variables within quotes.

Comment 8 Jan Pazdziora (Red Hat) 2013-03-18 07:57:18 UTC
Addressed in Spacewalk master, 29054252e2cfdb108677155ef9982c3d0d98a40a, 07504b3d868c91843d34d5ac49e2aefbdff4455f, and fe86281c6196199db80fb6689339e059656eab4c.

Comment 13 Clifford Perry 2013-10-01 21:52:33 UTC
Satellite 5.6 has been released. This bug was tracked under the release.  

This bug was either VERIFIED or RELEASE_PENDING (re-verified prior shortly
before release). 

Moving to CLOSED CURRENT_RELEASE. 

Text from Upgrade Erratum follows:

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-2013-1395.html


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