On Fri, Oct 21, 2011 at 12:50:17 +0200, Michal Toman wrote:
On 21.10.2011 12:16, Vratislav Podzimek wrote:
>I cannot agree with you. As I see the purpose of the "executable:
>SOMETHING" item in the bugreport it's used to differentiate between
>running /usr/bin/vim and /usr/bin/vimdiff (which is a symlink to
>the /usr/bin/vim). According to the value of argv[0] vim decides how it
>should run. And you can do exactly the same in Python and sys.argv[0].
Two different use-cases (Python exception vs. SELinux denial).
Sealert always sets executable to python which is not helpful at
all.
I see -- I overlooked the other use-case and assumed that the python
bindings are only used to report problems which have nothing to do with
current process (as is the case with Sealert).
On 20.10.2011 12:31, Martin Milata wrote:
>Doesn't really make sense, as it is always path to the python
>executable. bz#741255
>---
> [patch]
This *always* removes the executable field, when called from Python
binding. That will (at least) result into a different behavior of C
and Python API.
If I understand correctly, what we want to do is to remove the
executable (or executable == /usr/bin/python ?) from *SELinux*
report, no matter if called from C or Python.
I tried to solve it in a different way, patch should arrive as a reply
to this message.
Generally, I think that what we want to do is provide interfaces for
creating two kinds of reports -- reports about current process, where we
can detect things like executable, and reports about something else,
which is the case with sealert and where the caller should provide all
the information.