Bug 502473
| Summary: | Failure logging execve with lots of arguments | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | Red Hat Enterprise Linux 4 | Reporter: | Matthew Booth <mbooth> | ||||||
| Component: | kernel | Assignee: | Cong Wang <amwang> | ||||||
| Status: | CLOSED ERRATA | QA Contact: | Petr Beňas <pbenas> | ||||||
| Severity: | high | Docs Contact: | |||||||
| Priority: | medium | ||||||||
| Version: | 4.8 | CC: | eparis, pbenas, pstehlik, rkhan | ||||||
| Target Milestone: | rc | ||||||||
| Target Release: | --- | ||||||||
| Hardware: | i386 | ||||||||
| OS: | Linux | ||||||||
| Whiteboard: | |||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||
| Doc Text: | Story Points: | --- | |||||||
| Clone Of: | |||||||||
| : | 509134 (view as bug list) | Environment: | |||||||
| Last Closed: | 2011-02-16 15:56:41 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: | |||||||||
| Bug Depends On: | |||||||||
| Bug Blocks: | 509134 | ||||||||
| Attachments: |
|
||||||||
Looking at the gdb output, libaudit tells the kernel how big its buffer is. The kernels sends the record. Libaudit checks a few things and then calls the NLMSG_OK macro. The record fails this test, so I would also lean towards this being a kernel bug. Also, the RHEL4 user space implementation is not expecting split execve records. RHEL4 userspace has the choice of accepting split records or of handling records larger than 8k since RHEL4 can handle execve arguments >8k (always has been able to) Anyway the problem appears to be in my accounting of how much information I had sent to userspace. I forgot to account for the fact that strings are surrounded by "" Thus in this case when jamming 800+ arguments into one message my accounting was off by 800*2 bytes. Simple enough patch to fix my estimates. Created attachment 345543 [details]
fix message length accounting
This request was evaluated by Red Hat Product Management for inclusion in a Red Hat Enterprise Linux maintenance release. Product Management has requested further review of this request by Red Hat Engineering, for potential inclusion in a Red Hat Enterprise Linux Update release for currently deployed products. This request is not yet committed for inclusion in an Update release. Committed in 89.7.EL . RPMS are available at http://people.redhat.com/vgoyal/rhel4/ Reproduced in 89.6.EL and verified in 89.7.EL. An advisory has been issued which should help the problem described in this bug report. This report is therefore being closed with a resolution of ERRATA. For more information on therefore solution and/or where to find the updated files, please follow the link below. You may reopen this bug report if the solution does not work for you. http://rhn.redhat.com/errata/RHSA-2011-0263.html |
Created attachment 345304 [details] GDB session showing message received->return EBADE Description of problem: Execute the following command: seq 1 1000 | xargs echo In the output, you get a single EXECVE record, which start with this: type=EXECVE msg=audit(1243248052.942:49): a857="857" a858="858" The first 857 arguments have been lost. The kernel is, however, emitting the preceding record. I've attached some gdb output which shows the problem. Here's a snippet: 102 len = recvfrom(fd, &rep->msg, sizeof(rep->msg), block|peek, (gdb) n 105 if (len < 0) { (gdb) print rep->msg $4 = {nlh = {nlmsg_len = 9246, nlmsg_type = 1309, nlmsg_flags = 0, nlmsg_seq = 0, nlmsg_pid = 0}, data = "audit(1243249450.436:190): argc=1001 a0=\"echo\" a1=\"1\" a2=\"2\" a3=\"3\" a4=\"4\" a5=\"5\" a6=\"6\" a7=\"7\" a8=\"8\" a9=\"9\" a10=\"10\" a11=\"11\" a12=\"12\" a13=\"13\" a14=\"14\" a15=\"15\" a16=\"16\" a17=\"17\" a18=\"18\" a19=\"19\" "...} (gdb) print len $5 = 8476 I don't understand why only 8476 bytes have been returned, as sizeof(rep->msg) is 8970 bytes + sizeof(struct nlmsghdr). However, it appears that this is incomplete, which later results in EBADE being returned. This bug results in a predictable omission of data from the audit record. Version-Release number of selected component (if applicable): audit-libs-1.0.16-4.el4