Arthur Pemberton wrote:
So now threads are automatically evidence of a real problem?
A user problem is a real problem, whether developers care to acknowledge
it or not.
The OP
didn't even know whether or not SELinux was disabled/enabled till
after the thread started
That sort of goes along with my point... Why should this be a surprise
to the user?
With traditional unix security a few
simple checks can determine the status and any similar problem reported
to this list would have an immediate response with the fix or a test to
identify the problem. With this, we not only do not have an answer, in
the months this thread has continued, not only is there not a fix, no
one has produced a diagnostic test to even identify the issue.
I don't agree, the OP simply doesn't follow instructions and so in
capable of assisting with remote diagnosis.
But there haven't been any instructions other than handwaving about
reading and interpreting obscure logs. What specific test was suggested
that he failed to run?
How are you supposed to determine the 'correctness' of a given setup?
I don't understand what you mean by this.
If I asked how to determine whether or not some particular access would
be permitted or denied by the traditional unix mechanism you wouldn't
have any trouble describing how to verify it in terms of permissions
down the file path. I'm asking the same question about SELinux.
How, for example, would you determine if some change will make it
necessary to relabel? How, other than running something and letting it
fail to get the log message, do you positively determine that some
specific access will be permitted or denied?
--
Les Mikesell
lesmikesell@xxxxxxxxx
