Mail archive
acf

[acf] Re: [alpine-devel] Ideas for a new config framework, ACF2

From: Natanael Copa <ncopa_at_alpinelinux.org>
Date: Fri, 30 Nov 2012 14:52:03 +0100

Hi Ted,

On Thu, 29 Nov 2012 10:57:48 -0500
Ted Trask <ttrask01_at_yahoo.com> wrote:

> The proposed ACF2 seems to be a complete redesign to move from functional to data-driven design. Unfortunately, the doc does not give any reasons why this change is desired. What is the benefit? This change does not address any of the goals listed below. Just as a style preference, I've always been a C/functional design guy, rather than C++/object-oriented guy. I find object-oriented design more difficult to read and debug.
>
> See further comments below.
>
> On Nov 29, 2012, at 9:23 AM, Natanael Copa <ncopa_at_alpinelinux.org> wrote:
>
> > Some of the goals:
> > * better security design
>
> What is wrong with the security of the existing ACF?

* Everything is run as 'root'. You don't need root access to generate html.

* Lots of use of popen. This can go horrible wrong unless you take
  great care and know exactly what you are doing (I know you do but I
  consider this liek playing with fire).

> What would you do differently?

* Privilege separation. Drop root privileges unless you really need
  them. You don't need 'root' for menu generation or view if a service
  is running or not.

* Split the job into minor pieces. Instead of doing everything on one
  single http request, do multiple http requests each doing less work.
  The request for the menu data could drop privileges immediately while
  the request to edit a config file would keep the root privs.

* remove all html handling (view and controller) from server side. Less
  code on server side means less bugs.

* get rid of and forbid popen completely.

> > * remove unnecessary complexity from modules
>
> Can you give an example of the "unnecessary complexity" in the current ACF modules?

I'll let Kaarle answer to that.

> > * organize the libs better
>
> While I agree that the libs could be organized and, especially, documented better, what is the actual proposal here? There is nothing in the doc.

The proposal is so far only 'lets do this from scratch rather than try
fix current and break all current modules'.

We intend to start with the API rather than add it as an afterthought.
(I have my share of guilt that current ACF's API ended up as it did.)

We want full separation of model and presentation.
 
> > * fix concurrency - no race conditions
>
> This is a legitimate concern in the current ACF. The problem can be managed, not solved, with a daemon in the same manner as proposed for ACF2. However, there is nothing to prevent two users from overwriting each other's work.
>
> > * improve CLI interface
>
> I have done quite a bit of work for acf-core-0.15 to split out the web interface from the ACF core. As far as I can tell, there is now nothing preventing us from creating a functional CLI interface for ACF.

Do you still need to think HTML when making a CLI? Do we still need
pass parameters like submit="Create"?
Is the example in
http://git.alpinelinux.org/cgit/acf-core/tree/bin/acf-cli still valid?
(its a bad example btw as you should never pass over passwords via
command line. Only read via stdin)


> > * modernize web GUI (write the gui in javascript)
>
> I don't agree that "The full client-side approach eliminates all possible HTML-related security vulnerabilities". There is still a web server accepting the same requests. Nothing prevents a malicious user from directly accessing it.

If there are no HTML involved on the server side, how can there be
*HTML*-related security vulnerabilities?

The HTML problems themselves does not disappear, but we move them from
server to the client. HTML related vulnerabilities will no longer be a
threat to the server. Only to the client. Which is the point.

> I do agree that a single-page application has some advantages in user experience. However, there is nothing preventing us from creating a single-page application based on the current ACF. Any action can return it's result as JSON or as HTML without the surrounding skin/template.

Yes. But doing that on *all* the modules be almost the same as a
rewrite? Why not clean up the libs and APIs while doing so? Why not
start from scratch and see if it sticks instead of breaking everything
that currently works?

> > For web frontend we have been talking of using existing frameworks like
> > Backbone.js and RequireJS. For backend we have been talking about using
> > things like augeas and using Lua tables to create data models.
>
> I have known about augeas for some time, and there is nothing preventing us from using it with the current ACF. However, I have not felt the need to, because I have not created an ACF recently that could benefit from it. The existing ACF modules are working, so I have not felt the need to rewrite them.

As I understand, nothing prevents us to edit the files directly and
bypass augeas. We could also use SQL backends for some stuff. Thats
completely up to the presistance manager.

> This seems a good place to talk a bit more about the data-driven design, because augeas seems to be the genesis of the idea. While augeas allows you to modify the config files more safely, since it ensures the syntax is correct, I think it is better suited as a backend underneath a functional front end.

I think the idea is to use it as a backend behind the persistance
manager. The front end should not know, or care, if its augeas or sql or
anything in the backend.

We want separate out the storage handling from model implementation so
you can switch storage backend without changing the model.

> The augeas.net/tour.html page gives the simple example of adding an entry to the hosts file. The augeas user must know that a new entry can be added under /files/etc/hosts/ and that it should have values for ipaddr, canonical, and alias[]. Isn't it easier to see a web page with an "Add entry" button and an appropriate form?

I think the intention is to see a web page with an "Add entry" button.
But the backend does not need to know that there are any buttons at all.

> How can you automatically generate that button and form based upon the augeas output?

As I understand the proposal doc you would need to declare a mapping
between the model and augeas first.

> I think you would end up having to code the button and form into the model/view, which means you're going back to the functional design of ACF.

I think if GUI dev prefers that, that'll work too. I expect there be
toold to make the javeascript GUI in more declarative manner though.

>
> I see no benefit to the data-driven design when it comes to a user-facing application.

I think the idea is that it is not supposed to only be an user-facing
application. Should be able to add SNMP interface to it to. The CLI
makes it to a script-facing appliction.

> > This will require some massive work but I think we can do it. Hopefully
> > it will be simpler to write models once the basic framework is in place.
>
> I think it's pretty easy to write ACF modules.

Every time I have tried to do anything more advanced than create a
textbox input field in the *view* I have ended up fighting the
framework.

> As stated above, I think you would end up having to do the same work in ACF2 in order to get a user-friendly interface.

I hope to move much of the (repetitive) work that happens in the models
to the framework. Once we have a clear API and clean interfaces between
the different parts, it should be less work to add modules, and harder
to do mistakes that could threaten security.

I would also like it to be possible that different people does GUI that
does the backend stuff. That way you can contribute to GUI if you know
html and javascript but have no understanding of or interest in Lua and
vice versa.

> Sorry if the above sounds like a rant, but I legitimately don't understand the benefits of the proposal.
>
> Ted

Thanks for your comments!

-nc


---
Unsubscribe:  acf+unsubscribe_at_lists.alpinelinux.org
Help:         acf+help_at_lists.alpinelinux.org
---
Received on Fri Nov 30 2012 - 14:52:03 GMT