Bug 138692 - [request] [patch] 450.status-security should exit with rc=0
Summary: [request] [patch] 450.status-security should exit with rc=0
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: conf (show other bugs)
Version: 7.2-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: Alan Somers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-09-10 07:10 UTC by ben
Modified: 2017-08-25 02:19 UTC (History)
2 users (show)

See Also:
asomers: mfc-stable11?
asomers: mfc-stable10-


Attachments
file.diff (213 bytes, patch)
2009-09-10 07:10 UTC, ben
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description ben 2009-09-10 07:10:01 UTC
/etc/periodic/daily/450.status-security sets rc=3 when daily_status_security_enable="YES".  According to periodic(8), this means that the output "must not be masked."  However, this script only prints a single message or even nothing at all:

                case "${daily_status_security_output}" in
                    "")
                        ;;
                    /*)
                        echo "    (output logged separately)";;
                    *)
                        echo "    (output mailed separately)";;
                esac;;

Please apply the attached patch to set rc=0, to indicate that there is "nothing notable" in the output.

Fix: Patch is attached.

Patch attached with submission follows:
How-To-Repeat: Set daily_status_security_enable="YES" and run 'periodic daily'.
Comment 1 Remko Lodder 2009-09-11 06:20:23 UTC
>
>> Description:
> /etc/periodic/daily/450.status-security sets rc=3 when  
> daily_status_security_enable="YES".  According to periodic(8), this  
> means that the output "must not be masked."  However, this script  
> only prints a single message or even nothing at all:
>
>                case "${daily_status_security_output}" in
>                    "")
>                        ;;
>                    /*)
>                        echo "    (output logged separately)";;
>                    *)
>                        echo "    (output mailed separately)";;
>                esac;;
>
> Please apply the attached patch to set rc=0, to indicate that there  
> is "nothing notable" in the output.



This informs you that a security script had been runned and will  
report it's output via a different email (standard).
If you configure it to not be enabled at all; it wil tell you nothing.  
If you select the other option it will be logged via
a different way.

I do not see the arugments you are proposing. I think the current  
output is just fine, when I read my daily email
and see that there is additional output seperately; I will read that  
seperate email.

-- 
/"\   Best regards,                        | remko@FreeBSD.org
\ /   Remko Lodder                      | remko@EFnet
X    http://www.evilcoder.org/    |
/ \   ASCII Ribbon Campaign    | Against HTML Mail and News
Comment 2 Chris Cowart 2009-09-11 19:06:27 UTC
Remko Lodder wrote:
>>> Description:
>>/etc/periodic/daily/450.status-security sets rc=3 when
>>daily_status_security_enable="YES". According to periodic(8), this
>>means that the output "must not be masked." However, this script
>>only prints a single message or even nothing at all:
>>
>> case "${daily_status_security_output}" in
>> "")
>> ;;
>> /*)
>> echo " (output logged separately)";;
>> *)
>> echo " (output mailed separately)";;
>> esac;;
>>
>> Please apply the attached patch to set rc=0, to indicate that there
>> is "nothing notable" in the output.
>
> This informs you that a security script had been runned and will
> report it's output via a different email (standard).
> If you configure it to not be enabled at all; it wil tell you nothing.
> If you select the other option it will be logged via
> a different way.
> 
> I do not see the arugments you are proposing. I think the current
> output is just fine, when I read my daily email
> and see that there is additional output seperately; I will read that
> seperate email.


I believe there are a couple issues at work here. Firstly, while this
may not be a typical case, there are environments where someone
(hopefully a team) administers 100 or more FreeBSD servers. I certainly
work in one of these, and I believe Ben does too.

Part of the growing pains and a lesson of scalability comes on the day
you realize you're spending an hour paging through dailies, every day,
just to find the 1 or 2 e-mails with a small gem of information that you
care about. The rest is just noise and a waste of time.

On that day, you embark on a crusade to achieve the grand vision of "the
machine doesn't send me an e-mail unless it has something interesting to
say." Like a good system administrator, you consult the man page.
There's a sudden, rare moment of geeky hope and excitement when you
notice instructions in the man page that walk you through achieving
_exactly the thing you wanted to do_ (normally, you have to piece two or
three things together, try it out, rinse, repeat, etc.): "To only see
important information from daily periodic jobs, add the following lines
to /etc/periodic.conf...". So, you try it.

The next day, you get your periodics, and while they're considerably
shorter each, a lot of them had interesting definitions of "important
information." You sigh. Not exactly what you wanted, but it's never
_that easy_. You begin tuning. Oh, nagios is already monitoring disks
and portaudit? Disabled. IPFW denies traffic every day... that's why the
rule is there. Disabled. You get the idea. That should do it.

The next day, you get your periodics, but now you're starting to think
the man page was joking when it said "important information." I _nearly_
succeeded with quieting down the daily. Unfortunately, I'm still getting
one "daily run output" email from each host each day. Do you know what
"important" thing it thinks it needs to tell me?

| 
| Security check:
|     (output mailed separately)
| 
| -- End of daily output --
| 

Every. Single. Day. 130 copies. Delightful. But I want the security job
to run! I do! I'm very interested in the rc=1 and rc=3 output from those
jobs. So I leave it enabled and I hack procmail to hide these "success"
messages from me.

At first, I didn't understand why you thought Ben's argument was flawed.
Telling me the output was mailed separately is not noteworthy, not
remarkable, not uncommon. It's noise. It's rc=1. I didn't get it until I
looked more closely at the 450.status-security script.

Although it would improve my inbox volume the way I want it, Ben's patch
would cause the _entire security run_ output to masked in the case that
the output was configured to be inlined. That's because security runs
are a nested call to periodic. Unfortunately, periodic itself doesn't
return a different value depending on the "severity" of its output.

I would propose at _least_ the following patch to make the e-mail or
logged cases more sane and consistent with the documentation by
making it possible (and not by default, because by default, rc=0 causes
the output to be included) to suppress the "output (logged|mailed)
separately" lines:

| --- 450.status-security 2008-12-31 23:50:16.000000000 -0800
| +++ /home/ccowart/450.status-security   2009-09-11 10:56:08.000000000 -0700
| @@ -23,16 +23,17 @@
|         export security_output="${daily_status_security_output}"
|         case "${daily_status_security_output}" in
|             "")
| -           ;;
| +           rc=3;;
|             /*)
| -           echo "    (output logged separately)";;
| +           echo "    (output logged separately)"
| +           rc=0;;
|             *)
| -           echo "    (output mailed separately)";;
| +           echo "    (output mailed separately)"
| +           rc=0;;
|         esac;;
|     esac
|  
| -   periodic security
| -   rc=3;;
| +   periodic security || rc=3;;
|  
|      *)  rc=0;;
|  esac

Realistically, the problem is still going to exist in the inlined output
case (which I would prefer to use, because it means 1 email per machine
instead of two). Assume I configure the periodics to include the
security output inline. Now assume no security check has "noteworthy"
output (all rc=0, output_success=NO). The daily status-security is still
going to indicate non-maskable output (rc=3), and thus my daily will
look like:

| 
| Security check:
| 
| -- End of daily output --
| 

This is pretty lame, but I can't see a way around it without either 1)
disabling the security run in "daily" and setting up a separate cron for
it, or 2) doing some redesigning on periodic so its return code is a
function of the return codes of the scripts it runs. I think the latter
would be ideal, but I realize it's a much more significant undertaking.
The patch I'm suggesting above helps minimize the noise in the easy
(email or logged) case while preserving the inlined output as "notable"
given "periodic daily" can't currently determine whether it was
otherwise.

-- 
Chris Cowart
  http://www.timesinks.net/
Comment 3 dfilter service freebsd_committer freebsd_triage 2011-05-04 13:53:36 UTC
Author: netchild
Date: Wed May  4 12:48:02 2011
New Revision: 221432
URL: http://svn.freebsd.org/changeset/base/221432

Log:
  The security run requests unmaskable output, even if the only output is to
  tell that there is a separate email or that the output is logged to a file.
  
  This commit changes the return code for the non-inline case to tell that
  this message is not important enough and can be masked if necessary. The
  messages from the security checks themself are not affected by this and
  show up as before in the periodic security email/file.
  
  The inline case still requests to not mask the output, as with the current
  way of handling this there is no easy way to handle this.
  
  PR:			138692
  Analysis/patch atch by:	Chris Cowart <ccowart@timesinks.net>
  X-MFC after:		on request

Modified:
  head/etc/periodic/daily/450.status-security

Modified: head/etc/periodic/daily/450.status-security
==============================================================================
--- head/etc/periodic/daily/450.status-security	Wed May  4 12:44:46 2011	(r221431)
+++ head/etc/periodic/daily/450.status-security	Wed May  4 12:48:02 2011	(r221432)
@@ -23,16 +23,17 @@ case "$daily_status_security_enable" in
 		export security_output="${daily_status_security_output}"
 		case "${daily_status_security_output}" in
 		    "")
-			;;
+			rc=3;;
 		    /*)
-			echo "    (output logged separately)";;
+			echo "    (output logged separately)"
+			rc=0;;
 		    *)
-			echo "    (output mailed separately)";;
+			echo "    (output mailed separately)"
+			rc=0;;
 		esac;;
 	esac
 
-	periodic security
-	rc=3;;
+	periodic security || rc=3;;
 
     *)  rc=0;;
 esac
_______________________________________________
svn-src-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscribe@freebsd.org"
Comment 4 Alexander Leidinger freebsd_committer freebsd_triage 2011-05-04 13:53:39 UTC
State Changed
From-To: open->patched

Patch committed to -current. Thank you for this contribution. 


Comment 5 Alexander Leidinger freebsd_committer freebsd_triage 2011-05-04 13:53:39 UTC
Responsible Changed
From-To: freebsd-bugs->netchild

Patch committed to -current. Thank you for this contribution.
Comment 6 Clément Moulin 2012-04-26 15:17:25 UTC
Hi

Since 8 branch is still in use and this patch has not been backported :
  - adding "daily_status_security_enable=3DNO" to periodic.conf
  - specifying "security_output" in periodic.conf (you could set it to the =
same file/mail as daily_output)
  - adding an entry in crontab to run "periodic daily"
will do the trick !

Just my 2cts :)

--
Cl=E9ment Moulin
SimpleRezo
www.simplerezo.com
Comment 7 chrissicool 2015-01-13 17:42:32 UTC
This is still an issue. Any progress here?

I am running 10.1-RELEASE and if you have daily_status_security_enable=YES I still get a daily mail from 450.status-security, even if there is nothing to care about. This problem also persists on HEAD, since the file is identical.

The following patch snippet runs fine here.

---
        esac

-       periodic security || rc=3;;
+       periodic security ; rc=$?;;

    *)  rc=0;;
---

This simply forwards the result of the security script itself as a return code. The call to periodic should obey its own return codes.

Do I miss something?
Comment 8 chrissicool 2015-01-13 17:45:37 UTC
(In reply to chrissicool from comment #7)

Sorry, I meant daily_status_security_inline=YES.
Comment 9 Alan Somers freebsd_committer freebsd_triage 2017-04-06 20:29:26 UTC
Excellent screed, ccowart!  I believe this change fixes everyone's complaints, including when *_status_security_inline=YES

https://svnweb.freebsd.org/changeset/base/316548

If I don't hear from anyone for a couple of weeks, I'll close the bug.
Comment 10 Alan Somers freebsd_committer freebsd_triage 2017-04-24 16:19:41 UTC
Fixed by r316548.  MFC to stable/11 pending.  I have no plans to MFC to stable/10.
Comment 11 Alan Somers freebsd_committer freebsd_triage 2017-08-25 02:19:28 UTC
MFCed to stable/11 by r317554