Bug 184424 - [patch] newsyslog(8) run shell command feature does not work (R flag in config file)
Summary: [patch] newsyslog(8) run shell command feature does not work (R flag in confi...
Status: Open
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 9.1-RELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs mailing list
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2013-12-02 03:40 UTC by Klaas Teschauer
Modified: 2017-12-31 22:27 UTC (History)
0 users

See Also:


Attachments
file.diff (1.28 KB, patch)
2013-12-02 03:40 UTC, Klaas Teschauer
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
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