Support !syslog

[grifferz]

Describe the feature you'd like see implemented in sudo-rs
I'd like to be able to use the !syslog option from sudo.

What problem can be solved with this feature?
I have some automated processes which call sudo, and it's no use to me to have these fill logs all day every day. I create dedicated users for these commands and then set !syslog on them.

Describe alternatives you've considered
I can (and now do) use the pattern matching features of rsyslog to silently drop certain messages. I expect syslog-ng and other advanced syslogs can do similar. It's quite fiddly under systemd-journald.

[squell]

I've discussed this with a team member. On the plus side, this is pretty easy to implement (although that by itself isn't enough).

On the downside, filtering syslog messages via Defaults seems to offer less fine-grained control than filtering it using dedicated software that manage the system log (which can also solve this issue in general, for all software).

The limitation with Defaults !syslog is that you can configure it for a specific command, or for a specific user, but not both at the same time. Controlling logging using a dedicated NOLOG: tag would seem to me to be a strictly superior solution, e.g., that would allow picking really specific situations for disabling the syslog:

dedicated_user ALL=(runas) NOLOG: /sbin/ctlsomething

To help us understand the problem better: how much log messages would be sent by sudo-rs to the system log for these dedicated users? I.e. if left unchecked would it drown out other more useful messages? (A global figure suffices, e.g. n messages per time unit) And what kind of commands are these dedicated users running? (This helps us ascertain how common this usage scenario is).

As it stands, since the alternatives don't seem that unreasonable and there might be better solutions, I'm hesitant to start writing a patch immediately. But I'd like to keep this issue open to see if more people are looking for control over what sudo-rs sends to the syslog.

[grifferz]

Sorry, I wasn't aware that NOLOG: support existed. Does it? If so then it would be fine for my use case for me to enumerate all commands issued and apply the NOLOG: to each of them. I would not have submitted this issue if I realised.

As regards filtering syslog messages in the actual syslog server: it's a helpful workaround, but it does feel to me like it would be a "nice to have" feature in the programs that are actually generating the logs in the first place. i.e. I use syslog daemon filtering as a last resort to work around what I see as a lack of configurability in the originating program.

I do appreciate that what I consider unwelcome logging may be a very fringe requirement and not justify a change in any program. 😀

One real example I have is on my monitoring servers (running Icinga, a fork of Nagios). Some of the monitoring plugins need to run as root so they are being called with sudo hundreds of times per day, every invocation the same except for a target host. Before I added the syslog filtering for just that command log this amounted to approximately 180kB of log messages per hour.

I had previously silenced this by using !syslog as a Default for the nagios user. I could easily use NOLOG: on each individual command instead if that is available now or is planned. Each command that the nagios user issues does already have an entry in sudoers.

[mcassaniti]

If it helps, I have the following use case for checking that a systemd-sysupdate has updated and is waiting for a reboot to apply the update. This syntax below is valid (see the man page) , just not for sudo-rs. This executes every hour or so which is not heaps of noise, but it's enough. It will also be logging through to the systemd journal since this will take over syslog functionality.

# Allow all users to check for a pending update without logging the command
Cmnd_Alias SYSUPDATE = /usr/lib/systemd/systemd-sysupdate pending
Defaults!SYSUPDATE !log_allowed
ALL ALL = (root) NOPASSWD: SYSUPDATE

I also checked the code and I believe the NOLOG option is not currently present.