Bug 1121563 - [RFE] sendsyslog system call which simply passes a message up into syslogd's /dev/log interface
Summary: [RFE] sendsyslog system call which simply passes a message up into syslogd's ...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: kernel
Version: 7.2
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Seth Jennings
QA Contact: Red Hat Kernel QE team
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-07-21 08:47 UTC by Jiri Belka
Modified: 2018-10-12 20:22 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Enhancement
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-12 15:39:16 UTC


Attachments (Terms of Use)

Description Jiri Belka 2014-07-21 08:47:19 UTC
Description of problem:
OpenBSD added[1] new sendsyslog(const char *, size_t) system call which simply passes a message up into syslogd's /dev/log interface.  This will be used to make syslog_r work during file descriptor exhaustion, or inside sandboxes which
prohibit socket, connect, sendto, etc.
The system call is being added about a week before the library and daemon
changes.

It would be neat to have such thing in Linux kernel too. It would help logging in chroots (not mount --bind or other "tricks).

[1] http://marc.info/?l=openbsd-cvs&m=140498255523068&w=2

Version-Release number of selected component (if applicable):

How reproducible:


Steps to Reproduce:
1.
2.
3.

Actual results:


Expected results:


Additional info:

Comment 4 Seth Jennings 2015-11-09 21:44:14 UTC
I don't think that having a syscall is the right approach here.

Bind mounting directories or sockets into chrooted or container environments has really become the defacto solution here.  The advantage is that it put the host in control over the logging.  If the host doesn't want the container to log, it just doesn't set up the container-to-host logging bridge.

Many projects are building in systemd journal support like "systemd-nspawn --link-journal" and "docker --log-driver=journald"

This would face an additional challenge of acceptance upstream.

I believe the majority belief on this topic is that the container manager (docker, systemd-npsawn) should be responsible for setting up the logging.

If you agree, we can close.  If not, please elaborate on the situation in which you think that this is the best solution.

Comment 5 Jiri Belka 2015-11-12 08:53:56 UTC
Benefit of OpenBSD solution is logging would work even one would be out of FDs. Do whatever you want with this BZ.

Comment 6 Seth Jennings 2015-11-12 15:39:16 UTC
(In reply to Jiri Belka from comment #5)
> Benefit of OpenBSD solution is logging would work even one would be out of
> FDs.

True, but I see that being a rare case.  Probably means your system is either misbehaving or compromised :)  Either way, I don't see that being enough justification upstream.


Note You need to log in before you can comment on or make changes to this bug.