Bug 808389

Summary:	RFE: wizard style interface
Product:	[Fedora] Fedora	Reporter:	Karel Volný <kvolny>
Component:	setroubleshoot	Assignee:	Daniel Walsh <dwalsh>
Status:	CLOSED NOTABUG	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	17	CC:	dwalsh, mgrepl
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2013-04-24 19:45:20 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Karel Volný 2012-03-30 10:24:09 UTC

Description of problem:
Trying to use "SELinux Alert Browser", I was pretty confused how to use the interface. I guess it could be improved a bit ...

After clicking "Troubleshoot", there appeared a button to report a bug in the right-bottom corner of the window. But it was inactive. Now I could not understand why. Only after asking mgrepl I found that at first I have to click one of the big buttons on the left to get the buttons on the right activated.

I see two problems here:

1) The buttons on the left have a lot of text & free space on them. This is quite unusual - the common concept is that buttons in GUI are small, with only icon and/or short text on them, while longer descriptive text is beneath the button or in a tooltip. So I haven't identified them as buttons in the first place ... What would help me a lot would be if the bold sentence above the buttons would say something like "Select one of:" instead "Ak ste sa pokúšali o..." (= "If you were trying to..." or what is the untranslated message)

Note also that "radio buttons" are usually preferred when the choices are somehow equivalent.

2) Clicking the buttons on the left is superfluous and annoying, once I can see the desired "Report bug" button and click it directly - why to click something else at first to activate it to be able to use it?

What I would like to suggest is to implement

a) expert interface

which would look mostly like the current one, where the user can see all the options at once, but the difference would be that the user could go directly to the desired action without the need to activate the buttons by clicking something else

b) wizard interface

where the user will select one of the options, and only after that it would be shown what to do next ... the buttons not being inactive but rather not shown at all

- note also that in the current interface the button "Deatily zás. modulu" (= "Plugin details"?) is displayed twice, this is nonsense for such kind of interface, IMHO; this shouldn't happen both in a) and b) variants

Comment 1 Daniel Walsh 2012-03-30 17:00:31 UTC

What we are trying to do is not have the users first action be, report a bug. Since in a lot of cases he just needs to turn on a boolean or fix a label.  

I think a message at the top telling the User to select the "If" statement that matches his expectations, might be the best way to fix the issue you saw.

Comment 2 Karel Volný 2012-04-02 14:02:32 UTC

(In reply to comment #1)
> What we are trying to do is not have the users first action be, report a bug.

I bet removing the report button completely would have greater effect on discouraging users from reporting bugs ;-)

> Since in a lot of cases he just needs to turn on a boolean or fix a label.

this really should not be needed in a day-to-day usage, such need indicates a bug - selinux should deny only actions that are illegal, not those that are okay to be allowed

as the bug is not necesarily in the selinux/preconfigured policies itself, maybe the default could be reporting for the component that caused the denial, and then switching to selinux only if found that a valid action was denied, but it should be reported and fixed in any case

> I think a message at the top telling the User to select the "If" statement that
> matches his expectations, might be the best way to fix the issue you saw.

whatever that makes it clear(er) what do I need to do before trying to use the buttons on the right would be good ...

Comment 3 Miroslav Grepl 2012-04-02 14:27:59 UTC

(In reply to comment #2)
> (In reply to comment #1)
> > What we are trying to do is not have the users first action be, report a bug.
> 
> I bet removing the report button completely would have greater effect on
> discouraging users from reporting bugs ;-)
> 
> > Since in a lot of cases he just needs to turn on a boolean or fix a label.
> 
> this really should not be needed in a day-to-day usage, such need indicates a
> bug - selinux should deny only actions that are illegal, not those that are
> okay to be allowed

Well, I don't agree. Of course, we have man pages, but ... So we try to tell users what they could do if they have a configuration. For example you can use NFS/CIFS, you have a specific configuration for a daemon and so on.

And sure we can talk about security/usability but I believe we do a lot for it.

> 
> as the bug is not necesarily in the selinux/preconfigured policies itself,
> maybe the default could be reporting for the component that caused the denial,
> and then switching to selinux only if found that a valid action was denied, but
> it should be reported and fixed in any case
> 
> > I think a message at the top telling the User to select the "If" statement that
> > matches his expectations, might be the best way to fix the issue you saw.
> 
> whatever that makes it clear(er) what do I need to do before trying to use the
> buttons on the right would be good ...

Comment 4 Daniel Walsh 2012-04-02 19:08:38 UTC

Systems can be setup in a variety ways. Booleans are all about configuring a confined application in a way that is as tight as possible.   Apache for example can do just about anything an operating system is allowed to do .  But allowing it to read the credit card data out of my homedir, just because it might be setup that ways is not a good idea.  Similarly allowing the default apache setup to become a spam bot just because someone might want to setup apache to send mail, is not good security.

setroubleshoot is an effort to take a permission denied to an application and try to figure out the best solution for the problem.  Getting permission denied on DAC/Ownership/Permissions does not have any such app.

But admins understand what is going on here, but no so much when SELinux denies access.