Viewing Logs

Murus
megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Viewing Logs

Post by megumi » Sat Jan 03, 2015 10:36 pm

I used to be able to view logs by clicking on Tools > Logs in Murus' main window. I know this, because that's one of the things I had to do to figure out how to overcome FaceTime issues I was having only a few days ago. But today, I noticed that I can't view logs any more. If I click on Tools > Logs, a blank console windows for pffirewall.log appears, saying "You do not have permission to read this log." at the bottom.

I have not changed anything, as far as I know, and I have no idea why I can no longer see what I used to be able to see before. Please help me figure out what's going on.

P.S. Murus Logs Visualizer also opens blank windows for all logs and statistics.

hany
Posts: 484
Joined: Wed Dec 10, 2014 5:20 pm

Re: Viewing Logs

Post by hany » Sun Jan 04, 2015 1:59 pm

that's really strange. Try opening Console.app manually, choose the "/var/log" group in the left side view then select "pffirewall.log".
Anyway Murus does not change log file permission over time. You can verify log file permission from terminal:
ls -l /var/log/pffirewall.log
you should get something like:
-rw-r--r--@ 1 root wheel 2542996 4 Gen 14:33 /var/log/pffirewall.log
You can try fixing privileges using disk utility, it helped other Murus users.

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Sun Jan 04, 2015 4:07 pm

Thank you for your reply. I tried the terminal command you suggested, and got this:

Code: Select all

megumi$ ls -l /var/log/pffirewall.log
-rw-r-----  1 root  admin  745638  4 Jan 14:48 /var/log/pffirewall.log
I tried repairing permissions with Disk Utilities. It fixed many things (mostly files related to printer drivers), but did nothing to the pffirewall.log file.
I learned a few things about terminal commands and did these things:

Code: Select all

megumi$ ls -l /var/log/pffirewall*
-rw-r-----  1 root  admin  745638  4 Jan 14:48 /var/log/pffirewall.log
-rw-r-----  1 root  admin  368469  3 Jan 22:30 /var/log/pffirewall.log.0.bz2
-rw-r-----  1 root  admin  264281  2 Jan 12:37 /var/log/pffirewall.log.1.bz2
megumi$ sudo chown root:wheel /var/log/pffirewall*
Password:
megumi$ sudo chmod 644 /var/log/pffirewall*
megumi$ ls -l /var/log/pffirewall*
-rw-r--r--@ 1 root  wheel  863987  4 Jan 15:41 /var/log/pffirewall.log
-rw-r--r--@ 1 root  wheel  368469  3 Jan 22:30 /var/log/pffirewall.log.0.bz2
-rw-r--r--@ 1 root  wheel  264281  2 Jan 12:37 /var/log/pffirewall.log.1.bz2
Now, the console log shows both from Murus and from Murus Logs Visualizer, but from Murus Logs Visualizer, everything else shows blank windows - Realtime Simplified Logs, Logs Statistics, and Blocked/Passed Inbound/Outbound. I know things should be showing in those windows. I can see the pffirewall.log file scroll up, as it shows various pass and block entries in real time, but absolutely nothing shows in all Murus Logs Visualizer windows. Why? Are there any other files whose permissions need to be reset?

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Mon Jan 05, 2015 9:36 am

UPDATE
After restarting the computer, Murus Logs Visualizer is showing various data in every window now. I suppose Murus Logs Visualizer needed a restart before the new permissions settings of the log files take effect. I am not sure if simply restarting the program would have been enough, but rebooting the whole computer certainly seem to have worked. I am now happy.

I am curious about one remaining mystery. What caused the ownership/permission settings of the log files to change? I know for sure that I was able to see the log files in the first few days of using Murus, but toward the end of the first week, I suddenly found that I could no longer see the logs. At that point, with the help of the Murus developer, I discovered that the log files had wrong ownership/permission settings. How did that happen? If I resolve this mystery, I'll post here.

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Tue Jan 06, 2015 9:37 pm

UPDATE 2
The problem recurred. I can't see the logs, and from the terminal, I get this:

Code: Select all

megumi$ cd /var/log
megumi$ ls -l pffirewall*
-rw-r-----  1 root  admin  802560  6 Jan 21:09 pffirewall.log
-rw-r-----  1 root  admin  344886  6 Jan 14:23 pffirewall.log.0.bz2
-rw-r-----  1 root  admin  368469  3 Jan 22:30 pffirewall.log.1.bz2
-rw-r-----  1 root  admin  264281  2 Jan 12:37 pffirewall.log.2.bz2
Both ownership and permissions have changed. I don't quite know what caused these changes, but I note that there is one more log archive file since yesterday. I wonder if something goes wrong at the time of log rotation, when the log file reaches its maximum limit and gets archived. From what's written about this log rotation in the "Logs" tab of the Murus Preferences window, I understand that this is done by the OS (not by Murus).

I would appreciate any help from anyone to help me understand this mystery further and to prevent it from happening again.

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Tue Jan 06, 2015 11:05 pm

UPDATE 3

I searched the internet for "Mac OS X log rotation" and found that a command line utility 'newsy slog' seems responsible for log rotation for PF. I also found this Apple page (https://developer.apple.com/library/mac ... onf.5.html),
where it says: "The newsyslog.conf file is used to set log file rotation configuration for the newsyslog utility."
The configuration file did indeed exit on my HD:

Code: Select all

megumi$ ls -l /etc/newsyslog.conf
-rw-r--r--  1 root  wheel  1368  8 Nov 18:51 /etc/newsyslog.conf
 
I looked at the file content:

Code: Select all

megumi$ cat /etc/newsyslog.conf
# configuration file for newsyslog
# $FreeBSD: /repoman/r/ncvs/src/etc/newsyslog.conf,v 1.50 2005/03/02 00:40:55 brooks Exp $
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCGJNUWZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/ftp.log			640  5	   1000	*     J
/var/log/hwmond.log		640  5	   1000	*     J
/var/log/ipfw.log			640  5	   1000	*     J
/var/log/lpr.log			640  5	   1000	*     J
/var/log/ppp.log			640  5	   1000	*     J
/var/log/wtmp				644  3	   *	@01T05 B
/var/log/pffirewall.log		640  20	   5000	*     J
 
I edited the file to change the 640 to 644 in the last line for /var/log/pffirewall.log.

Code: Select all

Megumis-Laptop:~ megumi$ sudo pico /etc/newsyslog.conf
Password:
 

Code: Select all

  GNU nano 2.0.6                          File: /etc/newsyslog.conf                                                           

# configuration file for newsyslog
# $FreeBSD: /repoman/r/ncvs/src/etc/newsyslog.conf,v 1.50 2005/03/02 00:40:55 brooks Exp $
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCGJNUWZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/ftp.log			640  5	   1000	*     J
/var/log/hwmond.log		640  5	   1000	*     J
/var/log/ipfw.log			640  5	   1000	*     J
/var/log/lpr.log			640  5	   1000	*     J
/var/log/ppp.log			640  5	   1000	*     J
/var/log/wtmp				644  3	   *	@01T05 B
/var/log/pffirewall.log		644  20	   5000	*     J

                                             [ Read 26 lines ]
^G Get Help       ^O WriteOut       ^R Read File      ^Y Prev Page      ^K Cut Text       ^C Cur Pos
^X Exit           ^J Justify        ^W Where Is       ^V Next Page      ^U UnCut Text     ^T To Spell

Code: Select all

megumi$ cat /etc/newsyslog.conf
# configuration file for newsyslog
# $FreeBSD: /repoman/r/ncvs/src/etc/newsyslog.conf,v 1.50 2005/03/02 00:40:55 brooks Exp $
#
# Entries which do not specify the '/pid_file' field will cause the
# syslogd process to be signalled when that log file is rotated.  This
# action is only appropriate for log files which are written to by the
# syslogd process (ie, files listed in /etc/syslog.conf).  If there
# is no process which needs to be signalled when a given log file is
# rotated, then the entry for that file should include the 'N' flag.
#
# The 'flags' field is one or more of the letters: BCGJNUWZ or a '-'.
#
# Note: some sites will want to select more restrictive protections than the
# defaults.  In particular, it may be desirable to switch many of the 644
# entries to 640 or 600.  For example, some sites will consider the
# contents of maillog, messages, and lpd-errs to be confidential.  In the
# future, these defaults may change to more conservative ones.
#
# logfilename          [owner:group]    mode count size when  flags [/pid_file] [sig_num]
/var/log/ftp.log			640  5	   1000	*     J
/var/log/hwmond.log		640  5	   1000	*     J
/var/log/ipfw.log			640  5	   1000	*     J
/var/log/lpr.log			640  5	   1000	*     J
/var/log/ppp.log			640  5	   1000	*     J
/var/log/wtmp				644  3	   *	@01T05 B
/var/log/pffirewall.log		644  20	   5000	*     J
 
Hopefully from the next rotation, the file permission settings for pffirewall.log will allow a normal unprivileged user to read it. Apparently, the default file ownership is root:admin, but as long as the read permission is given to everyone, that shouldn't matter.

Log rotation should happen tomorrow. I'll post another update after it happens to report if this fix will work.

hany
Posts: 484
Joined: Wed Dec 10, 2014 5:20 pm

Re: Viewing Logs

Post by hany » Wed Jan 07, 2015 1:55 pm

Hello megumi
well, you fund a Murus bug.
Murus is responsible for modifying file /etc/newsyslog.conf. Actually it set permission 640 on pffirewall.log, while it should be 644.
For this reason, if you are not an administrator, you can't read the log file. Logs Visualizer runs with the same privileges as the current logged in user, so if the user is not an administrator, Logs Visualizer will not show logs.
Sorry about that, we will fix this bug as soon as possible.

WORKAROUNDS:
manually modify file permission for /var/log/pfffirewall.log and modify /etc/newsyslog.conf in order to fix the bug.
Permission for log file should be 644 not 640. So change log file permission using this shell command:
sudo chmod 644 /var/log/pffirewall.log
Then edit the configuration file /var/log/newsyslog.conf. You just need to change the last line:
from:
/var/log/pffirewall.log 640 10 20000 * J
to:
/var/log/pffirewall.log 644 10 20000 * J

Thanks so much megumi for helping us understanding this bug. It is really appreciated :) Let me now, tomorrow, if the file has correct permissions after rotation.

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Wed Jan 07, 2015 5:06 pm

Hello hany,

Thank you for your helpful post.

Looking at the log, I found the log file size was 2.5 MB. So, I thought I would change the maximum file size from the default 5 MB to 3 MB in the Murus Preferences in order to make the log rotation happen sooner. But, when I moved the slide bar to 3 MB and clicked on 'Save Log File Rotation Settings' button, the window opens, saying "Sorry, you must install Boot Scripts from Murus 'Firewall' menu in order to activate logging and change logging policy", even though I have already installed the Boot Scripts before. Even after rebooting the computer, the file /etc/newsyslog.conf still shows exactly the same as before for /var/log/pffirewall.log - count:20, size:5000.

How can I change the logging policy?

hany
Posts: 484
Joined: Wed Dec 10, 2014 5:20 pm

Re: Viewing Logs

Post by hany » Wed Jan 07, 2015 5:33 pm

Hi
you can get the error message "Sorry, you must install Boot Scripts from Murus 'Firewall' menu in order to activate logging and change logging policy" for 2 reasons:
1) you did not install boot scripts
2) you manually removed file /etc/newsyslog.conf.BACKUP.

Actually Murus applies logging policy changes to file /etc/nesyslog.conf only if file /etc/newsyslog.conf.BACKUP exists and if file /etc/newsyslog.conf contains a line for /var/log/pffirewall.log. Both conditions indicates that the user has installed Murus boot script. Probably during your tests you removed the .BACKUP file and now Murus does not allow you to edit logs policy. If this is the case, just copy your newsyslog.conf to newsyslog.conf.BACKUP and retry.

P.S.
modifying log policy restores the "640" permissions on newsyslog.conf. So you actually have to take care doing this :)
We plan to release a Murus update tomorrow, in order to fix this issue.

megumi
Posts: 37
Joined: Wed Dec 31, 2014 2:31 pm

Re: Viewing Logs

Post by megumi » Wed Jan 07, 2015 10:46 pm

Hello hany,

Thank you for your explanation. I did as you said, and I confirm that I was able to change the logging policy from Murus preferences. The maximum file size is now reduced from 5 MB to 4MB. As you pointed out, the permission setting changed to 640. I manually changed it back to 644. The current size of the log file is 3.7 MB, so soon I will be able to see what happens at the next log rotation.

By the way, as far as I know, I did not delete any files when I was trying to modify the /etc/newsyslog.conf. I was somewhat afraid of making a mess of things, so I was consciously very careful. If there was /etc/newsyslog.conf.BACKUP, I would have seen it and would not have deleted it. As far as I remember, I did not see such a file. I don't think there was that file. If that is the case, the next question is why wasn't it there? I am wondering if the BACKUP file was ever created in the first place. Is it Murus that is suppose to create the file? If so, when is it supposed to happen?

Post Reply