Bug 547000
Summary: | openlog(xx, 0, LOG_KERN) acts like openlog(xx, 0, LOG_USER) | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Denys Vlasenko <dvlasenk> |
Component: | man-pages | Assignee: | Ivana Varekova <varekova> |
Status: | CLOSED INSUFFICIENT_DATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | medium | Docs Contact: | |
Priority: | low | ||
Version: | rawhide | CC: | jakub, schwab, varekova |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2010-02-15 07:39:13 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Denys Vlasenko
2009-12-13 04:30:07 UTC
Man page of openlog states: LOG_KERN kernel messages (these can't be generated from user processes) ...but there is no way to prevent it. Any process can open a socket to "/dev/log" and write a string "<0>Voila, a LOG_KERN + LOG_EMERG message!" there. Making openlog(xx, xx, LOG_KERN) intentionally broken does not help one iota in preventing this sort of "attack". It only makes writing legitimate code (e.g. klogd) harder. As far as I see, "man openlog" does not state that "facility" argument in openlog() call can be set to 0, or that LOG_KERN is prohibited. As I see it, programmers should not pass 0 there since such usage is not documented, they should pass LOG_USER if that's the facility they want. To forestall future improper usage, it makes sense to amend "(default)" at LOG_USER in manpage. Now it looks like this: LOG_USER (default) generic user-level messages How about "(default if openlog was not called explicitly)" ? Hello, please could you clarify, why this is not glibc bug and this is expected behaviour and attach here the patch for man-pages which will fix the issue. Andreas, could you please clarify what is the right behaviour and describe describe here the man-page change fix? Hello, there was no replay whether the behavior is wanted and man-page should be fixed or not. SZo I'm closing the bug (insufficient_data). |