https://github.com/c-blake/kslog

Minimalistic Kernel-Syslogd For Linux in Nim
https://github.com/c-blake/kslog

Last synced: 5 days ago
JSON representation

Minimalistic Kernel-Syslogd For Linux in Nim

• Host: GitHub
• URL: https://github.com/c-blake/kslog
• Owner: c-blake
• License: isc
• Created: 2020-01-28T21:38:44.000Z (almost 5 years ago)
• Default Branch: master
• Last Pushed: 2024-10-28T13:06:56.000Z (17 days ago)
• Last Synced: 2024-10-28T16:50:52.361Z (17 days ago)
• Language: Nim
• Size: 50.8 KB
• Stars: 12
• Watchers: 3
• Forks: 0
• Open Issues: 0
• Metadata Files:
  • Readme: README.md
  • License: LICENSE

Awesome Lists containing this project

• awesome-systemd - kslog - syslogd for (systemd-journald)
• awesome-systemd - kslog - syslogd for (systemd-journald)

README

        
Privilege and Complexity

========================

I mostly wrote this because I wanted to run my kernel/system logger not as

root.  I looked into doing this with `syslog-ng` and it seemed hard to get

right.  `CAP_SYS_ADMIN` or whatnot also seem used.  I had a hunch that over

the years feature bloat had exploded sysloggers beyond reason making what I

wanted unnecessarily difficult.  For what most people use it for, it should

really be a simple program anyway.  syslog-ng is over 300,000 lines of C.

Even busybox syslogd clocks in at over 1,000 lines.

Instead of all that jazz, I give you `kslog` - under 200 lines of Nim that

likely does all you really need in two easy pieces - a few dozen line easily

audited privileged `kslog_open.nim` and 125-ish line `kslog.nim`.

Sadly, `kslog-open` (*not* `kslog`) must run as root to manipulate `/dev/`.

At this late date, there is probably no relocating of `/dev/log` or making

binding of Unix domain sockets easier.  This opening phase is *all* `kslog`

needs elevated privilege for.  `kslog-open` just does this minimal work to

set up input file descriptors 0,3 and then drops privilege & exec's `kslog`.

`kslog` itself only needs permission to open its output files for write.

If said output files already exist with `syslog`-user writable permission,

the `syslog` user need not even have permission to create new files in

`/var/log`.  Wide ability to write to `/dev/log` always affords an easy

fill-the-disk attack, of course.

Log Contents

=============

Priority & facility numbers are retained in `kslog` logs.  I doubt there is a

better way to learn how to filter out informational|debug messages by altering

`maxLevel` than looking at a big list of examples.  `grep '\