SELinux last straw

[Les Mikesell]

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 at gmail.com