[apparmor] [yast-devel] apparmor: Texteditor

[Goldwyn Rodrigues]

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 <rgoldwyn at suse.de> 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