mirror of
https://github.com/pygos/usyslog.git
synced 2024-11-17 10:17:10 +01:00
118 lines
4.9 KiB
Markdown
118 lines
4.9 KiB
Markdown
# About
|
|
|
|
This package contains a tiny syslogd implementation called `usyslogd` and
|
|
accompanying utilities, such as a tiny `klogd` that forwards kernel message
|
|
to syslog and a utility program called `syslog` that can be used to generate
|
|
syslog message from the command line or shell scripts.
|
|
|
|
The syslog daemon opens a socket in `/dev/log`, processes syslog messages and
|
|
forwards the parsed message to a modular backend interface.
|
|
|
|
Currently, there is only one implementation of the backend interface that dumps
|
|
the log messages into files in the processes working directory (by default
|
|
`/var/log`).
|
|
|
|
A simple log rotation scheme has been implemented.
|
|
|
|
## License
|
|
|
|
The source code in this package is provided under the OpenBSD flavored ISC
|
|
license. So you can practically do as you wish, as long as you retain the
|
|
original copyright notice.
|
|
|
|
|
|
## Portability
|
|
|
|
The programs in this package have been written for and tested on a GNU/Linux
|
|
system, so their may be some GNU-isms in there in addition to Linux specific
|
|
code.
|
|
|
|
The `usyslogd` implementation has not been written to any specifications but
|
|
instead to work with the messages generated by Musl libc. It may not properly
|
|
parse the formats generated by other libc implementations or by programs that
|
|
roll their own.
|
|
|
|
The `klogd` daemon is Linux specific but independent of the syslog
|
|
implementation and could in theory be used with other syslog daemons.
|
|
|
|
The `syslog` utility program only uses functionality form the standard C
|
|
library and should *in theory* work on any modern GNU/Linux or BSD system.
|
|
The facility IDs may need to be adjusted (it uses the ones from `usyslogd`).
|
|
|
|
|
|
The file backend of `usyslogd` tries to take over ownership of `/var/log`
|
|
and make it inaccessible for all other users. This may be an issue if some
|
|
program tries to put its own log files there as non-root user, or programs
|
|
that try to read from them as non-root (e.g. `utmp`, `btmp`, `wtmp`, `faillog`,
|
|
`lastlog`).
|
|
|
|
|
|
# The syslog implementation
|
|
|
|
## Security Considerations
|
|
|
|
By default, the daemon switches its working directory to `/var/log`. The
|
|
directory is created if it doesn't exist and the daemon always tries to
|
|
change its mode to one that doesn't allow other users (except group members)
|
|
to access the directory.
|
|
|
|
If told to so on the command line, the daemon chroots to the log directory.
|
|
|
|
By default, the daemon then tries to drop privileges by switching to user and
|
|
group named `syslogd` if they exist (any other user or group can be specified
|
|
on the command line; doing so causes syslogd to fail if they don't exist).
|
|
|
|
|
|
On a system that hosts accounts for multiple users that may be more or less
|
|
trusted, one may consider only giving system services access to the syslog
|
|
socket and not allowing regular users. Otherwise, a user may flood the syslog
|
|
daemon with messages, possibly leading to resource starvation, or (in the case
|
|
of size limited log rotation outlined below) to the loss of otherwise critical
|
|
log messages. Since this is not the primary target of the Pygos system that
|
|
this package has been written for, such a mechanism is not yet implemented.
|
|
|
|
In case of a system where only daemons are running, the above mentioned
|
|
security measure is useless. If a remote attacker manages to get regular user
|
|
privileges, you already have a different, much greater problem. Also, a remote
|
|
attacker would have to compromise a local daemon that already has special
|
|
access to the syslog socket, which is again your least concern in this
|
|
scenario.
|
|
|
|
|
|
## Logrotation
|
|
|
|
The backend can be configured to do log rotation in a continuous fashion (i.e.
|
|
in a way that log messages aren't lost), or in a way where it drops old
|
|
messages. Furthermore, the backend can be configured to automatically do a log
|
|
rotation if a certain size threshold is hit.
|
|
|
|
If the `usyslogd` receives a `SIGHUP`, it tells the backend to do log rotation.
|
|
|
|
In the case of the size threshold, the backend is expected to do the rotation
|
|
on its own if the predetermined limit is hit.
|
|
|
|
|
|
## File Based Backend
|
|
|
|
The file based backend writes log messages to files in the current working
|
|
directory (by default `/var/log`), named either after the ident string (if
|
|
specified) or the facility name.
|
|
|
|
Log messages are prefixed with an ISO 8601 time stamp, optionally the facility
|
|
name (unless part of the file name), the log level and the senders PID. Each
|
|
of those fields is enclosed in brackets.
|
|
|
|
Log rotation in a continuous fashion means renaming the existing log file to
|
|
one suffixed with the current time stamp. Overwriting old messages renaming
|
|
the log file by appending a constant `.1` suffix.
|
|
|
|
|
|
# Possible Future Directions
|
|
|
|
In the near term future, the daemon probably requires more fine grained control
|
|
over logging such as setting a minimum log level or a way to configure limits
|
|
per facility or service.
|
|
|
|
Future directions may include adding other backends, such as forwarding the
|
|
log messages to a central server, for instance using syslog over UDP/TCP or
|
|
using the front end of some time series database.
|