Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

tools: set ownership of syslog created log file to frr #4379

Closed
wants to merge 1 commit into from
Closed

tools: set ownership of syslog created log file to frr #4379

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
tools: set ownership of syslog created log file to frr 
Problem reported with errors if "log file /var/log/frr/frr.log" is
entered and the file had been created by syslog with root ownership.
This fix sets the ownership to frr/frrvty so that the file can be
referenced and defined within frr if syslog created it.

Signed-off-by: Don Slice <dslice@cumulusnetworks.com>
Ticket: CM-18981
  • Loading branch information
@dslicenc
dslicenc committed May 21, 2019
commit cffa7033b8f5fadfdcb005a88b489740a075e046
6 changes: 6 additions & 0 deletions tools/etc/rsyslog.d/45-frr.conf
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,6 +1,12 @@
# The lines below cause all FRR daemons and process to go
# to /var/log/frr/frr.log, then drops the message so it does
# not also go to /var/log/syslog, so the messages are not duplicated
# Set file ownership of the frr.log file so frr can reference it from
# CLI. Without this, log file is created with root ownership which can
# cause issues.

$FileOwner frr
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ok so I just looked at the rsyslogd docs and these are global configuration parameters, which affect all following statements (the doc for $FileOwner and $FileGroup doesn't say specifically, but $FileCreateMode does and I think it's reasonable to assume these 3 work the same way.)

That would mean that the effect of these statements is not limited to 45-frr.conf (or the frr.log file created) but rather extends to any other logging config loaded after it, e.g. 50-foobar.conf.

I'm only 60% confident on this (I use syslog-ng personally), but this definitely needs to be confirmed or invalidated.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the feedback. I'll check into whether this is true or not and find alternatives.

$FileGroup frrvty
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

In addition to the intrusion problem described in my conversation comment, I'm not convinced frrvty is the right group here. It's the group that controls vty access, which human operator users can be added to so they can use vtysh without being root. If we want to give them read access, then this makes sense, but then we also need to make sure the permissions are 0640. If the permissions include group write, this opens a hole that suddenly allows operators to tamper with the logs. If the permissions are 0644, the group doesn't matter.

So either this is accompanied by a permission setting to 0640, or the group setting is underdetermined in its effect and needs to go.


$outchannel frr_log,/var/log/frr/frr.log
if $programname == 'babeld' or
Expand Down