Description of problem: According to the man page - satpasswd is only executable by root. But in testing a non-privileged user can execute satpasswd and reset the Satellite Administrator's password. Version-Release number of selected component (if applicable): 5.4 How reproducible: Very Steps to Reproduce: 1. Install Satellite Server and assign a password to the Satellite Administrator 2. Create a non-privileged user on the satellite server using useradd and passwd 3. Login to the server as the non-privileged user and issue satpasswd <Satellite Administrator> Actual results: The non-privileged user can reset the Satellite Administrator's password Expected results: According to the man page - Due to the nature of the command, access to it is restricted to the root user. Additional info:
According to the script this is not supposed to be utilized for embedded databases: # NOTICE: The use of this code/script is only for the use with RHN # Satellite and an external database. It is not permitted to use this # script within RHN Satellite and an embedded database. Should a check be put in place to 1. check for an embedded database and 2. check if root is running the script? Here is an example of what I have tested. Insert at line 18 of existing script. RHNSAT=/rhnsat # Check for existence of /rhnsat directory if [ -d $RHNSAT ];then echo "It is not permitted to use this script with an embedded database" exit fi # Check if root is running the script if [ $UID != '0' ]; then echo "You must be root in order to execute this script." exit fi
Should have also put in there to change the mode to 700.
Taking.
What is the issue in this bugzilla -- is it the mismatch of the manual page with the actual behaviour of the command, or is it the fact that any non-root user can change the password? If it's the second one, then the main issue here is that anybody with account on the Satellite box can connect to the Oracle account with the data if they know the password. In other words, bug 485355. If it's the first one -- I'd much rather change the man page. As for the NOTICE in the source code, that one is actually gone in upstream as it made no sense.
No, it was not. I assume the change of the permissions on the file happened after you've applied errata http://rhn.redhat.com/errata/RHSA-2011-0434.html. In fact, the permissions of that file as recorded in the rpm database are correct (0640, root:apache), the problem is that ./install.pl (and spacewalk-setup which is run from that) changes the permissions. So the fact that you see this addresses is just a coincidence and any future ./install.pl --upgrade will revert to the incorrect permissions.
Fix bug 485355 addressed, running satpasswd as a user who does not have access to /etc/rhn/rhn.conf fails, with $ satpasswd admin Traceback (most recent call last): File "/usr/bin/spacewalk-cfg-get", line 25, in ? cfg.parse() File "/usr/share/rhn/common/rhnConfig.py", line 121, in parse timeDiff = self.modifiedYN() File "/usr/share/rhn/common/rhnConfig.py", line 103, in modifiedYN self.file, e.args[1]) common.rhnConfig.ConfigParserError: ('config file read error', '/etc/rhn/rhn.conf', 'Permission denied') Traceback (most recent call last): File "/usr/bin/spacewalk-cfg-get", line 25, in ? cfg.parse() File "/usr/share/rhn/common/rhnConfig.py", line 121, in parse timeDiff = self.modifiedYN() File "/usr/share/rhn/common/rhnConfig.py", line 103, in modifiedYN self.file, e.args[1]) common.rhnConfig.ConfigParserError: ('config file read error', '/etc/rhn/rhn.conf', 'Permission denied') user "admin" is not a valid satellite user $ While running it as root works: # satpasswd admin Password: Retype password: # Moving ON_QA.
Non-privileged user isn't able to change satellite admin's password. However the traceback that is printed for this user isn't correct (Created Bug 709359). Stage validated on Satellite-5.4.1-RHEL6-re20110530.0
An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. https://rhn.redhat.com/errata/RHEA-2011-0875.html