summaryrefslogtreecommitdiff
path: root/src/misc/syslog.c
AgeCommit message (Collapse)AuthorLines
2013-03-23fix multiple bugs in syslog interfacesRich Felker-24/+27
1. as reported by William Haddon, the value returned by snprintf was wrongly used as a length passed to sendto, despite it possibly exceeding the buffer length. this could lead to invalid reads and leaking additional data to syslog. 2. openlog was storing a pointer to the ident string passed by the caller, rather than copying it. this bug is shared with (and even documented in) other implementations like glibc, but such behavior does not seem to meet the requirements of the standard. 3. extremely long ident provided to openlog, or corrupt ident due to the above issue, could possibly have resulted in buffer overflows. despite having the potential for smashing the stack, i believe the impact is low since ident points to a short string literal in typical application usage (and per the above bug, other usages will break horribly on other implementations). 4. when used with LOG_NDELAY, openlog was not connecting the newly-opened socket; sendto was being used instead. this defeated the main purpose of LOG_NDELAY: preparing for chroot. 5. the default facility was not being used at all, so all messages without an explicit facility passed to syslog were getting logged at the kernel facility. 6. setlogmask was not thread-safe; no synchronization was performed updating the mask. the fix uses atomics rather than locking to avoid introducing a lock in the fast path for messages whose priority is not in the mask. 7. in some code paths, the syslog lock was being unlocked twice; this could result in releasing a lock that was actually held by a different thread. some additional enhancements to syslog such as a default identifier based on argv[0] or similar may still be desired; at this time, only the above-listed bugs have been fixed.
2012-09-29emulate SOCK_CLOEXEC and SOCK_NONBLOCK for old (pre-2.6.27) kernelsRich Felker-2/+1
also update syslog to use SOCK_CLOEXEC rather than separate fcntl step, to make it safe in multithreaded programs that run external programs. emulation is not atomic; it could be made atomic by holding a lock on forking during the operation, but this seems like overkill. my goal is not to achieve perfect behavior on old kernels (which have plenty of other imperfect behavior already) but to avoid catastrophic breakage in (1) syslog, which would give no output on old kernels with the change to use SOCK_CLOEXEC, and (2) programs built on a new kernel where configure scripts detected a working SOCK_CLOEXEC, which later get run on older kernels (they may otherwise fail to work completely).
2012-04-24ditch the priority inheritance locks; use malloc's version of lockRich Felker-9/+9
i did some testing trying to switch malloc to use the new internal lock with priority inheritance, and my malloc contention test got 20-100 times slower. if priority inheritance futexes are this slow, it's simply too high a price to pay for avoiding priority inversion. maybe we can consider them somewhere down the road once the kernel folks get their act together on this (and perferably don't link it to glibc's inefficient lock API)... as such, i've switch __lock to use malloc's implementation of lightweight locks, and updated all the users of the code to use an array with a waiter count for their locks. this should give optimal performance in the vast majority of cases, and it's simple. malloc is still using its own internal copy of the lock code because it seems to yield measurably better performance with -O3 when it's inlined (20% or more difference in the contention stress test).
2011-04-18protect syslog against cancellationRich Felker-5/+19
these functions are allowed to be cancellation points, but then we would have to install cleanup handlers to avoid termination with locks held.
2011-04-13simplify syslog, add vsyslog interface (nonstandard)Rich Felker-31/+36
with datagram sockets, depending on fprintf not to flush the output early was very fragile; the new version simply uses a small fixed-size buffer. it could be updated to dynamic-allocate large buffers if needed, but i can't envision any admin being happy about finding 64kb-long lines in their syslog...
2011-04-13remove useless SIGPIPE protection from syslogRich Felker-9/+0
per the standard, SIGPIPE is not generated for SOCK_DGRAM.
2011-04-13fix syslog (corrected SIGPIPE blocking, and using dgram instead of stream)Rich Felker-10/+8
it actually appears the hacks to block SIGPIPE are probably not necessary, and potentially harmful. if i can confirm this, i'll remove them.
2011-02-12initial check-in, version 0.5.0v0.5.0Rich Felker-0/+115