Re: Another selinux rant

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

 



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".

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

Ralf



-- 
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