On Wed, 2011-10-26 at 12:47 +0200, Martin Milata wrote:
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.
I think that the key is not to override info provided from "caller" (like in the attached patch) and patch "callers" to provide it correctly. It's the same for python-meh where I'am doing it right now.
-- Vratislav Podzimek