...

...

On 04/03/2017 at 16:25, in message <20170403162556.0d281d7d@pepa.labs.suse.cz>, Josef Reidinger wrote: On Mon, 3 Apr 2017 09:13:27 -0500 Goldwyn Rodrigues wrote:

...

Cross post apparmor+yast mailing list.

Hi Goldwyn,

...

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.

What do you think of the idea?

At first, thanks for hacking on yast2-apparmor, which definively need some love. At second, I am not sure if text editor is good idea. Yast goal should be at first to provide easy to setup tool with guidance, so it is fine if very expect only options are not in GUI. To be honest I do not see much advantage in text editor in YaST against specialized text editors. Of course what you can do is to start from yast $EDITOR and after exit do something, but we have no builtin support for it.

In past similar think is done by sudo, which have its editor, that visudo, but it can be done quite easily with `$EDITOR %1 and apparmor_parser`.

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 would see this as two separate things: 1) Editor for file - my guess here is that we won't make a better editor than the one the user is used to using :-) 2) Validating file - this sounds like a good first step. Perhaps just offer functionality to parse said file and present useful feedback to the user? Just my two cents :-p Kenneth Wimer UI/UX Team Lead SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409 Nürnberg, Germany Phone: +49 911 740 53-669 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

...

...

On 04/04/2017 at 01:00, in message <22603812.fgmShBOELW@tux.boltz.de.vu>, Christian Boltz wrote: Hello,

Am Montag, 3. April 2017, 16:58:42 CEST schrieb Kenneth Wimer:

...

Josef Reidinger wrote:

...

...

At second, I am not sure if text editor is good idea. Yast goal should be at first to provide easy to setup tool with guidance, so it is fine if very expect only options are not in GUI.

...

...

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.

My opinion on this is:

With the JSON interface added to the AppArmor tools, YaST will get back the UI for aa-logprof and aa-genprof (for interactively updating and generating profiles).

I'd consider manually editing a profile an expert task (not in the sense that it's complicated, but non-experts probably prefer using aa-logprof or the YaST interface of it), so adding a plain editor doesn't make too much sense IMHO ;-)

Two crazy ideas:

- implement a minimal profile editor in YaST, that can _only_ edit profile variables in /etc/apparmor.d/tunables/* That's something that could be useful for non-experts, for example to set the dovecot mailstore location for the dovecot profiles. (Be warned that even this isn't as simple as it might look ;-)

- implement a profile editor with something like PyQt - it could use the apparmor.rule.* python classes directly and therefore offer a real value. (Of course, PyQt would mean that it only works in the graphical interface.) Such an editor would live in upstream AppArmor, YaST could just call it.

Note that both ideas (especially the PyQt-based editor) are just ideas. I won't add them to my TODO list - I already have vim ;-)

...

I would see this as two separate things:

1) Editor for file - my guess here is that we won't make a better editor than the one the user is used to using :-)

Adding an editor to YaST would offer a completely new option in the editor wars! ;-)

On a more serious note: you might want to use vim for AppArmor profiles because it has syntax highlighting.

...

2) Validating file - this sounds like a good first step. Perhaps just offer functionality to parse said file and present useful feedback to the user?

I agree it would be useful, but if there is no "edit profile" button, a "validate profile" button might cause some confusion ("why does YaST offer to validate a profile if I can't edit it in YaST?")

Maybe something along the lines of the SOC Crowbar barclamp editor? It supports a set of pre-defined options/keys as well as a simple text editor for the file (raw view). Kenneth Wimer UI/UX Team Lead SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 (AG Nürnberg) Maxfeldstr. 5, D-90409 Nürnberg, Germany Phone: +49 911 740 53-669 -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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). 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. -- Goldwyn -- To unsubscribe, e-mail: yast-devel+unsubscribe@opensuse.org To contact the owner, e-mail: yast-devel+owner@opensuse.org

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