It turns out that audit and selinux were modified to slightly change the
behavior of getprocattr.
The changes are:
1. when the audit subsystem calls security_getprocattr it only allows
for a return code of EINVAL
2. when the audit subsystem calls security_getprocattr with the size
paramter set to 0. It expects the returned size to be the size
that would be put in the buffer.
This behavior is undocumented in LSM but the changes showed up in
audit and selinux.
This patch fixes AA so that when 0 is passed it will return the size
that would have been read. This in turn fixes the problem where the
audit system spits out a ton of
error in audit_log_task_context messages
the AA getprocattr handling can still return error messages that are
not EINVAL but these should not happen in the audit log context unless
audit makes an error.
The possible places are:
- audit passes a buffer that is to small - this shouldn't happen since
audit uses the return value from a prob with parameter size == 0
- audit task context is trying to read a /proc/<pid>/attr/current that is
the current tasks context.
This shouldn't happen since the task context is for the current task.
- memory allocation fails
This one will generate the message but the audit code its self will
generate the message if its allocation fails.
bashisms which were in place to get around PWD not getting set
correctly. Instead, fix the simple.pl script to call pwd directly.
Based on feedback from PLD/Arkadiusz Miskiewicz <arekm@maven.pl>.
the openSUSE 10.2 RC candidates. This is because the _syscallN macros
are (apparently) no longer user visible. This patch replaces uses of
_syscallN() in the regression test source with invocations of syscall(2),
the preferred linux kernel way of doing things. With this patch, our
regression tests compile on the openSUSE 10.2 candidates as well as older
distributions (tested as far back as slackware 10.0, which includes a
2.4.x kernel).
(A missing license header got added as well as some minor coding style
cleanups leaked into the patch as well.)
Fix the help text in the edit profile dialog. As well as closing the
<code> block mentioned in the bug report, it also converts the list of
actions under the "add entry" drop down to an actual unorded list, and
adds a missing "Edit Entry" (useless) description.
Unfortunately, it also means changes to translated strings, though the
changes should be mechanical in nature and not require understanding
the languages themselves.
the former isn't supported on glibc before glibc 2.4 (SL10.0 and prior,
Annvix, etc.). I dislike the change because fdopendir() does exactly
what I want, and converting to straight opendir() introduces a small
race window, though paths in question should be under administrator
control anyway.
automatically added to the set of languages to be built and installed
unless they are explicitly added to the set of disabled translations.
This eliminates the need to manually add a lang to the Makefile when a
new translation is submitted (svn add will still be necessary).
