On Tue, Sep 08, 2015 at 11:53:33PM +0100, KatolaZ wrote:
> On Tue, Sep 08, 2015 at 09:40:12PM +0200, Edward Bartolo wrote:
> > Hi all,
> >
> > I think, a simple way to avoid the backend having to call external
> > programs like ifup and ifdown, is to use code belonging to these
> > programs as it they were functions. This means, their code would be
> > used like this:
> >
> > Suppose int main(int argc, char * argv[]) is the main function for
> > ifup. The main function's name would be changed like this, and the
> > other code belonging to ifup would be used.
> >
> > int ifup_main(int argc, char * argv[]);
> >
> > If I am correct, this should allow the backend to avoid having to use
> > execl to call ifup or ifdown or whatever other external program.
> >
>
> So you are basically suggesting that your backend should swallow ifup,
> ifdown and who knows how many other executables, just because you
> don't want to call execl? No matter where the code of ifup lives, it
> requires root privileges to do anything relevant, so having it inside
> your backend won't avoid having at least one executable with SUID set
> (the backend), or launched by init as a daemon (and thus owned by
> root).
>
> I still don't see why on Earth you want to "avoid having to use execl
> to call ifup". Esecuting an existing command-line program into a child
> is exactly what the wide majority of all the ncurses and GUIs
> frontends (not just for network config) actually do. This is the
> normal way of doing things.
>
> "Incorporating code from other programs" == "bloating your little
> software".

Which has implications for maintainability. Your code won't benefit
from bug fixes made to ifup.

Except, of course, the ifup code is a thin command-language wrapper
around a shared library or system call that does the actual work; then
just calling the shared library or system call is OK.


-- hendrik