Bug 188006
Summary: | curl generates execmem and execstack avc granted log messages | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Paul Howarth <paul> |
Component: | curl | Assignee: | Ivana Varekova <varekova> |
Status: | CLOSED NOTABUG | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 5 | CC: | daniel, drepper, dwalsh |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | i386 | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2006-04-05 17:20:59 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
Paul Howarth
2006-04-05 11:21:00 UTC
What exactly should we patch upstream? I don't have (access to) any box running FC5 nor any other SELinux so I would appreciate some further details, or preferably a suggested patch! Some information on what's being checked and possible workarounds can be found at: http://people.redhat.com/drepper/selinux-mem.html Unfortunately I don't know anything about curl's internals myself so I can't help with a patch. Sorry, but that page didn't make any bells ring... Is it perhaps possible to force a core dump for the possible violations so that a gdb backtrace would reveal where it occurs? Of course someone with this setup enabled could use gdb to step through the code to see when/why this alert happens. Or is there anything else I can do? I don't see any such message when I use curl in a simple test. You'll have to provide a receipe to reproduce it. Also, adjust the hardware field of the bug to the one you see the bug on (unless you can really see the problem on more than one architecture). execstack errors are the easiest to track down. Just look at the DSOs which are loaded and look at their program header (eu-readelf -l /path/to/dso). There must be a GNU_STACK line. If this is missing or the permissions (second to last field) is RWX instead of RW you found the culprit. Aha. Problem solved. I had a home-made libidn 0.6.3 package built on Red Hat 9 installed (with no GNU_STACK line). I built it on Red Hat 9 so it would install on later distro versions without dependency issues. Rebuilding on FC5 fixed the problem. Thanks for the clue. |