On 10/17/07, Les Mikesell <lesmikesell@xxxxxxxxx> wrote: > 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. So basically I can create 10 threads right now, and you consider that to be 10 problems? > > 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? It isn't. There are clearly defined methods, both console and GUI which could have been used to determine this. Something can only be made so easy. The only way it would be easier to get this info would be to have a modal dialog saying off/on on every boot. > >> 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? provide a complete log. the only snippet he provided immediately showed SELinux to _not_ be the one reporting problems. > >> 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. 1) familiarize ones self with the rules , as one has to do with traditional secuirty 2) or just try it and see if it is allowed or not > 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? perms can be viewed with `ls` and there is some command that provides the current settings. How would you do it with traditional tools? -- Fedora 7 : sipping some of that moonshine ( www.pembo13.com ) -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list
