Bug 184424

Summary: [patch] newsyslog(8) run shell command feature does not work (R flag in config file)
Product: Base System Reporter: Klaas Teschauer <ktsr42>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Open ---    
Severity: Affects Only Me Keywords: patch
Priority: Normal    
Version: 9.1-RELEASE   
Hardware: Any   
OS: Any   
Attachments:
Description Flags
file.diff none

Description Klaas Teschauer 2013-12-02 03:40:00 UTC
According to newsyslog.conf(5), newsyslog offers a feature to execute an external command to signal a daemon after a log has been rotated.

Quoting man newsyslog.conf, section "flags":

             R       if this flag is set the newsyslog(8) will run shell com-
                     mand defined in path_to_pid_cmd_file after rotation
                     instead of trying to send signal to a process id stored
                     in the file.

In FreeBSD 9.1, this feature does not work.

Fix: A patch is attached to this report. Here is the output from newsyslog with it:

[klaas@hub ~]$ ./hacks/newsyslog/newsyslog -f newsyslog.netatalk.test -r -n -v -F
Processing newsyslog.netatalk.test
/var/log/netatalk.log <6>: size (Kb): 5 [50] --> trimming log....
        rm -f /var/log/netatalk.log.6
        rm -f /var/log/netatalk.log.6.gz
        rm -f /var/log/netatalk.log.6.bz2
        rm -f /var/log/netatalk.log.6.xz
        rm -f /var/log/netatalk.log.5
        rm -f /var/log/netatalk.log.5.gz
        rm -f /var/log/netatalk.log.5.bz2
        rm -f /var/log/netatalk.log.5.xz
        mv /var/log/netatalk.log.2.gz /var/log/netatalk.log.3.gz
        chmod 644 /var/log/netatalk.log.3.gz
        chown 0:0 /var/log/netatalk.log.3.gz
        mv /var/log/netatalk.log.1.gz /var/log/netatalk.log.2.gz
        chmod 644 /var/log/netatalk.log.2.gz
        chown 0:0 /var/log/netatalk.log.2.gz
        mv /var/log/netatalk.log.0 /var/log/netatalk.log.1
        chmod 644 /var/log/netatalk.log.1
        chown 0:0 /var/log/netatalk.log.1
        ln /var/log/netatalk.log /var/log/netatalk.log.0
        chmod 644 /var/log/netatalk.log.0
        chown 0:0 /var/log/netatalk.log.0
Start new log...
        mktemp /var/log/netatalk.log.zXXXXXX
        chown 0:0 /var/log/netatalk.log.zXXXXXX
        chmod 644 /var/log/netatalk.log.zXXXXXX
        mv /var/log/netatalk.log.zXXXXXX /var/log/netatalk.log
Signal all daemon process(es)...
do_sigwork: /usr/home/klaas/restart.netatalk, run_cmd 1, pidok 0, pid 0
noaction: 1
Run command: /usr/home/klaas/restart.netatalk 1
        sleep 10

Warning: This patch has not been tested in any way. I only confirmed that things seem to happen as expected when running newsyslog with -n and -v.

Other notes:

1) I am not sure why the original implementation of do_sigwork() passes the signal number to the external program. It seems to he redundant because I would expect the dedicated script to know what to do. 

2) I am no security expert, but in my mind the system() call from stdlib is a security risk. system() passes the string to the sh command interpreter and thus is open to manipulation of the search path. I would recommend that newsyslog uses fork/exec for calling external programs, including kill(1).

Patch attached with submission follows:
How-To-Repeat: Set up a newsyslog.conf file with an entry that uses the 'R' flag:

[klaas@hub ~]$ cat newsyslog.netatalk.test 
# test config for newsyslog(8)

# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/netatalk.log  root:wheel       644     6  50   @T00  R    /usr/home/klaas/restart.netatalk

Perform a test run to confirm that the script is not invoked (due to the bug):

[klaas@hub ~]$ newsyslog -f newsyslog.netatalk.test -r -n -v -F
Processing newsyslog.netatalk.test
/var/log/netatalk.log <6>: size (Kb): 5 [50] --> trimming log....
        rm -f /var/log/netatalk.log.6
        rm -f /var/log/netatalk.log.6.gz
        rm -f /var/log/netatalk.log.6.bz2
        rm -f /var/log/netatalk.log.6.xz
        rm -f /var/log/netatalk.log.5
        rm -f /var/log/netatalk.log.5.gz
        rm -f /var/log/netatalk.log.5.bz2
        rm -f /var/log/netatalk.log.5.xz
        mv /var/log/netatalk.log.2.gz /var/log/netatalk.log.3.gz
        chmod 644 /var/log/netatalk.log.3.gz
        chown 0:0 /var/log/netatalk.log.3.gz
        mv /var/log/netatalk.log.1.gz /var/log/netatalk.log.2.gz
        chmod 644 /var/log/netatalk.log.2.gz
        chown 0:0 /var/log/netatalk.log.2.gz
        mv /var/log/netatalk.log.0 /var/log/netatalk.log.1
        chmod 644 /var/log/netatalk.log.1
        chown 0:0 /var/log/netatalk.log.1
        ln /var/log/netatalk.log /var/log/netatalk.log.0
        chmod 644 /var/log/netatalk.log.0
        chown 0:0 /var/log/netatalk.log.0
Start new log...
        mktemp /var/log/netatalk.log.zXXXXXX
        chown 0:0 /var/log/netatalk.log.zXXXXXX
        chmod 644 /var/log/netatalk.log.zXXXXXX
        mv /var/log/netatalk.log.zXXXXXX /var/log/netatalk.log
Signal all daemon process(es)...
        sleep 10
Comment 1 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 07:59:11 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 2 Graham Perrin freebsd_committer freebsd_triage 2022-10-17 12:37:01 UTC
Keyword: 

    patch
or  patch-ready

– in lieu of summary line prefix: 

    [patch]

* bulk change for the keyword
* summary lines may be edited manually (not in bulk). 

Keyword descriptions and search interface: 

    <https://bugs.freebsd.org/bugzilla/describekeywords.cgi>