Mailinglist Archive: yast-devel (42 mails)

< Previous Next >
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 <rgoldwyn@xxxxxxx> 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
<rgoldwyn@xxxxxxx> 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@xxxxxxxxxxxx
To contact the owner, e-mail: yast-devel+owner@xxxxxxxxxxxx

< Previous Next >