Re: [apparmor] [yast-devel] apparmor: Texteditor

On 04/05/2017 09:50 AM, Josef Reidinger wrote:

On Wed, 5 Apr 2017 09:35:37 -0500 Goldwyn Rodrigues wrote:

...

On 04/04/2017 10:15 AM, Ladislav Slezak wrote:

...

Dne 3.4.2017 v 16:25 Josef Reidinger napsal(a):

...

On Mon, 3 Apr 2017 09:13:27 -0500 Goldwyn Rodrigues wrote: [...]

...

While hacking on yast-apparmor to remove perl library dependency, we discussed on apparmor mailing list that we cannot have all possible options and the information in yast to facilitate modification of configuration files. So, a dumb text editor would be the best option to configuration. After the user modifies the file, it would checked by apparmor_parser for validity.

However, I could not find any options in Yast which would provide a text editor or I din't look in the right places.

There is no full text editor in YaST. But as a workaround you could use the MultiLineEdit widget [1]. It's a simple text field but allows editing multi line text. In GUI you can use at least the basic shortcuts like Ctrl+C and Ctrl+V. Another advantage is that is works also in the text mode and does not need any external tools.

In the past we used this trick in the bootloader module, you could display the proposed configuration and manually edit it. Then it was read and parsed back. This way you could set the options which were otherwise not available in the UI.

However I'd avoid this approach, see below.

[...]

...

In general I think yast goal is to allows non-expert to do common configuration, so support options that majority of users find useful. Of course, it is not easy to judge what is still common and what is expert only, but we should keep common sense. For example enabling debugging is probably not something common user need, another example is OWLSM enablement can be there with proper info that it can break setup.

I fully agree with that. The goal should not be covering 100% of the available options and configuration possibilities in YaST.

That leads to overly complex UI which is hard to use by non-experts. On the other hand experts would probably use a terminal and their favorite editor avoiding YaST completely.

Focus on the common cases, make them easy and understandable. For complex or unusual cases point users to the documentation and manual tools.

The only important thing for YaST is to keep the manual changes, or at least warn users when they will be overwritten if keeping them would be too complex or impossible.

So to summarize: Yast does not need to cover all the options, just the important ones. However focus should be on the ease of use.

So this is how I think we should do this.

1. Put all the logic in yast, in the form of hashmap with what options are compatible with which keywords. 2. Keep this hashmap in a separate file, so it makes it easier to update. 3. Present it to user in a dropdown menu/radio button/checkbox interface. 4. Validate the final profile file using apparmor_parser. This should be a BUG() sequence for the developer to fix rather than telling the user that s/he misconfigured.

The disadvantage with this approach is that we will not have an uptodate list presented by apparmor. But I think we can live with that since we are not trying to achieve 100% coverage. Besides, we are duplicating logic (from apparmor).

Well, beside keeping this set of options up to date, for me bigger disadvantage is that you as user get list of options and values you can set, without any hint what option is safe, what is danger, without any context what is option useful for what. In general I do not see advantage over opening file in text editor. This can be fine if you together with hashmap also describe what each option do and what each keyword do, but I worry if we do it for each option, it is incredible amount of work and I think this can became nightmare from maintenance perspective.

...

My concern is, how do we handle the case where the users has a config option not understood by yast, and the user tries to edit it. Mark it un-editable?

You may propose something else if you find this proposal absolutely preposterous.

Still my proposal is to find common user configuration goals and try to make it easy for user to achieve such goals. Like e.g. wizard to set protection for given daemon?

We already have that. Given a daemon, we can find what files etc. it will use and generate and optimum configuration: aa-genprof generates an apparmor profile. We will be using these tools in yast soon enough once I get through the review comments (for json support) from the apparmor community. Besides, there are other options such as scanning the log files and updating the profiles based on the warnings generated (aa-logprof). I am currently working on incorporating that as well. Background (Sorry, should have mentioned earlier): This whole discussion is about how to edit a given configuration and yet be free of the perl library yast-apparmor depends on. Appamor utils are currently written in python and we don't have a reliable bridge between python and ruby (I have tried those). apparmor's perl library is not maintained and the main reason why we are unable to upgrade apparmor in TW. If you are suggesting these tools/interfaces are enough and we don't have to edit the profiles in yast, I am fine with that ;) -- Goldwyn -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org