Re: Another selinux rant

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Ralf Corsepius wrote:
On Sat, 2008-01-05 at 01:36 -0600, Arthur Pemberton wrote:
On Jan 5, 2008 12:33 AM, Ralf Corsepius <rc040203@xxxxxxxxxx> wrote:
On Fri, 2008-01-04 at 12:07 -0500, John Dennis wrote:
Ed Swierk wrote:
People who already know about SELinux can of course just learn to type
ls -l --lcontext, but showing the extra information by default would
at least give clueless users like me a hint that files have these
extra attributes that might somehow be relevant to those strange
openvpn failures. IMHO this would be the single best usability
improvement to SELinux
Re SELinux usability issues:

We wrote the setroubleshoot package precisely to help SELinux novice
users so they wouldn't suffer with hidden obscure failures of the type
which have frustrated you. If it had been installed you would have
received notifications in real time on your desktop describing the
failure and suggestions on how to fix it.
Well, honorable goal, but does it actually achieve this goal?

* On one machine (FC8/x86_64), for me, all setroubleshoot does is to die
shortly after bootup and first-time login (I haven't tried to
investigate, but as it seems to me some serelated daemon is
segfaulting).
You don't possibly think that this is the regular behaviour of
setroubleshoot on which you cna judge it?
No, I am pretty certain it's an setroubleshoot and/or its infrastructure
bug.

* Is it appropriate to inform arbitrary ordinary users about SELinux
issues? May-be this on single user/non-networked machines, but I don't
think this is the right concept for a networked environment in which
"ordinary user" normally isn't the system admin.
I'm not sure i understand the criticism here.
The question behind this: To whom are SELinux messages/is setroubleshoot
of interest and who is able to react upon them?

In production systems, it's the system admin and nobody else.

For example, think about an "ordinary (SMB) office" situation. Most of such a system's users will not administrate their machines by themselves, many of these users will be computer illiterates. All setroubleshoot offers to them is "clutter" to their desktop for
issues which are "none of their business".

Naturally... which is the reason those users should not have setroubleshoot available to them... the name itself should make this obvious. Its a tool made for the development phase of a technology, not for a production system in a typical office environment.

In a "Linux-geek@home"/"personal desktop" scenario, the situation is
different. IMO, this is the scenario Fedora's current setroubleshoot is
appropriate for.

Yes, I've personally found it very helpful in testing rawhide in this scenario.

--
Andrew Farris <lordmorgul@xxxxxxxxx> <ajfarris@xxxxxxxxx>
 gpg 0xC99B1DF3 fingerprint CDEC 6FAD BA27 40DF 707E A2E0 F0F6 E622 C99B 1DF3
No one now has, and no one will ever again get, the big picture. - Daniel Geer
----                                                                       ----

--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux