• 1
Setroubleshoot is more detailed now a days and that's awesome the "Hash" at bottom gives you a rough idea if you want to create your own policy :)

While I empathise with the "the tooling gave you enough information you could have figured it out yourself" nature of the post (and have been on the receiving end of a bunch of reports like that), it seems to me that 61 lines of output (of which "If you believe $TOOL should be allowed... access on the $FILE_FOR_TOOL by default... then you should report a bug" is most of the volume, which implies to the skim reader it's more important) isn't exactly helping the less-than-expert user understand that it's not working because they're "doing it wrong".

A couple of suggestions:
1. I'd suggest not displaying the catchall information if there are is at least one (significantly) higher confidence option, unless there's some sort of "I don't like the advice, give me something else" command line option (eg, a --verbose, or --generic advice or --show-workarounds). The default advice can always end with a single line that says something like "run $FOO --show-workarounds for more alternatives". (If there's nothing else to suggest then yes maybe show the catch all by default.)

2. The first two options are functionally identical problems ("the file has the wrong label") yet (a) fail to say explicitly "the file has the wrong label", and (b) fail to point out that there are two ways to have it get correct label (ie, "put it in the standard directory" and "manually set the label on the file") rather than, eg, just being to cargo-cult things to do (the third one, the generic work around, is very cargo-cult). Even just starting with "OpenVPN is not permitted to read files labeled $LABEL_ON_PROBLEM_CRT_FILE; it needs a different label" would seriously improve the usability of the advice for someone in a rush. (I know that's what the audit message means, you know that's what the audit message means, but the average user reporting it to bugzilla clearly doesn't: if they did understand, they'd have relabeled without even needing setroubleshoot.)

Just to be clear, I think setroubleshoot is a huge improvement on the pre-setroubleshoot days. But I also thing there's scope to divert more of the "it's broken, please fix" generic reports by having it provide advice it has figured out in a more readable manner (ie, concise, to the point, with specific fixes).


PS: If there's an obvious way that users should be getting those certificates onto the system in such a way that they automatically get labelled correctly, it'd be a really good idea to document that prominently. If every approach requires "do something then run restorecon" then IMHO that's a usability bug, since it's a poor solution to the average use case for using OpenVPN (viz, someone gives you a certificate, you copy it onto your system and try to use it). Just saying.

These are all good ideas, and something we should consider for our next redesign, which should be happening in F21 with full integration into journald. Makeing automatic messages that do not say something stupid is sometimes difficult. But I agree in this case giving the user the option to submit a bug, should be buried.

I also agree that the real bug here is NetworkManager, which I believe the user used to load his Certificate should have fixed the label or copied the Certificate into the ~/.cert or !/.pki directory with the correct label, then the user would never have seen this issue.

Some people don't run GUI, what about "wall'ing" a message to the last active console?

Well we are starting to put the messages in the journald. As I blogged a couple of weeks ago.


I think if we just walled the message, it would not make people happy. Also there is a message in /var/log/messages, telling the admin how to get this info.

Finally you could setup setroubleshoot to send you email.


Still not a SeLinux fan, adds another layer of troubleshooting and one more thing I have to turn off and suddenly things work again. I know it's all opensource and I have even created my own fedora based distro without SeLinux. The reason I don't read it is because I don't use it and no matter how awesome the message, the fact there's a message telling my I can't run the vpn (or in your case access the cert) software that I obviously installed to run a vpn is more then slightly annoying, it's just stupid to have to deal with.

Yes Security can sometimes be hard and SELinux is not for everyone, which is why we make it fairly easy to enable/disable it.

  • 1

Log in