[apparmor] [yast-devel] apparmor: Texteditor

Goldwyn Rodrigues rgoldwyn at suse.de
Wed Apr 5 14:35:37 UTC 2017

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

You may propose something else if you find this proposal absolutely


More information about the AppArmor mailing list