Bug 484720 - /bin/ln -s /opt/notification/cron/notification /etc/cron.d/notification not needed in /etc/sudoers
/bin/ln -s /opt/notification/cron/notification /etc/cron.d/notification not n...
Product: Red Hat Satellite 5
Classification: Red Hat
Component: Server (Show other bugs)
All Linux
low Severity medium
: ---
: ---
Assigned To: Miroslav Suchý
wes hayutin
Depends On:
Blocks: 457079
  Show dependency treegraph
Reported: 2009-02-09 11:46 EST by Jan Pazdziora
Modified: 2009-09-10 15:12 EDT (History)
3 users (show)

See Also:
Fixed In Version: sat530
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-09-10 15:12:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Jan Pazdziora 2009-02-09 11:46:19 EST
Description of problem:

The default installation of Satellite 5.3.0 adds /bin/ln -s /opt/notification/cron/notification /etc/cron.d/notification to alias INSTALL_RHN in /etc/sudoers.

I've grepped Spacewalk source and /bin/ln does not appear to be used anywhere. Moreover, /etc/cron.d/notification is a file, owned by NPalert:

# rpm -qf /etc/cron.d/notification
# ls -dla /etc/cron.d/notification
-rw-r--r-- 1 root root 136 Jan 16 12:37 /etc/cron.d/notification

Therefore I assume that /bin/ln thing can be removed from /etc/sudoers.

Note: I did this scan through our code to figure out if there are some commands that need additional SELinux treatment.

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


How reproducible:


Steps to Reproduce:
1. Install Satellite 5.3.0.
2. Look into /etc/sudoers.
Actual results:

/bin/ln is there.

Expected results:

/bin/ln is not there and Satellite continues to work OK.

Additional info:

This bug was modeled based on bug 484718.
Comment 1 Jan Pazdziora 2009-02-09 11:47:20 EST
While we're at it, that /bin/rm /etc/cron.d/notification, should go as well.
Comment 2 Jan Pazdziora 2009-02-10 07:25:29 EST
The proposed change is to remove the INSTALL_RHN section and merge whatever needs to be there to CONFIG_RHN. The proposed sudoers.rhn is below. I've tested that with this, the Satellite/Spacewalk works and runs external commands fine.

## RHN specifics ##
Cmnd_Alias CONFIG_RHN = /usr/sbin/rhn-sat-restart-silent,\
                        /etc/rc.d/np.d/step Monitoring install,\
                        /etc/rc.d/np.d/step MonitoringScout install,\
                        /etc/rc.d/np.d/step Monitoring uninstall,\
                        /etc/rc.d/np.d/step MonitoringScout uninstall,\
                        /sbin/service Monitoring restart,\
                        /sbin/service MonitoringScout restart,\
                        /sbin/service taskomatic restart

# The CONFIG_RHN commands are required for reconfiguration of a
# running RHN Satellite.  They should be enabled for proper operation
# of the RHN Satellite.
apache  ALL=(root)      NOPASSWD: CONFIG_RHN
tomcat  ALL=(root)      NOPASSWD: CONFIG_RHN

# These two directives allow tomcat and apache to invoke CONFIG_RHN
# commands via sudo even without a real tty
Defaults:tomcat !requiretty
Defaults:apache !requiretty
Comment 3 Clifford Perry 2009-02-10 11:45:05 EST
Need to make sure it is not a shadow file, where we own the file within rpm but do not put it onto disk. 

Also - how about within WebUI when you enable and disable both monitoring scout and monitoring backend - I assume the file should be removed / added as needed when monitoring is enabled/disabled as a whole on a Satellite. 

Comment 4 Jan Pazdziora 2009-02-11 03:37:48 EST
NPalert.spec does:

in %install

# Install the cron stuff
mkdir -p $RPM_BUILD_ROOT%{_sysconfdir}/cron.d/
install -p -m 644 cron/notification        $RPM_BUILD_ROOT%{_sysconfdir}/cron.d/notification

in %files


So the file looks real.

Furthermore, I've grepped the whole Spacewalk source code for /usr/bin/sudo and that cp and rm are nowhere found via sudo in our code anymore.

So I assume it's safe to remove.

The cron file has

*/15 * * * * nocpulse  if [ -e /etc/NOCpulse.ini ] ; then /usr/bin/monitor-queue ALERTS 50 100 2>&1 > /dev/null; fi

in it so it seems that the existence of /etc/NOCpulse.ini rather than existence  of /etc/cron.d/notification triggers the action.
Comment 5 Miroslav Suchý 2009-02-12 05:18:58 EST
Commited as:
Comment 6 Miroslav Suchý 2009-02-16 05:08:19 EST
Mass moving ON_QA
Comment 7 wes hayutin 2009-02-18 09:51:26 EST
[root@grandprix ~]# cat /etc/sudoers  | grep -i ln
[root@grandprix ~]# 

[root@grandprix cron.d]# cat notification 
# Check system load
*/15 * * * * nocpulse  if [ -e /etc/NOCpulse.ini ] ; then /usr/bin/monitor-queue ALERTS 50 100 2>&1 > /dev/null; fi
[root@grandprix cron.d]# 

[root@grandprix cron.d]# cat /etc/sudoers  | grep -i rm
## Delegating permissions
[root@grandprix cron.d]# cat /etc/sudoers  | grep -i notification
[root@grandprix cron.d]# 

Comment 8 Milan Zázrivec 2009-09-02 10:58:19 EDT
Verified in stage with the same results as stated in the comment
Comment 9 Brandon Perkins 2009-09-10 15:12:05 EDT
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.


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