#536 error checking needs robustifying

0.980
closed
Jamie Cameron
5
2002-06-26
2002-06-26
Anonymous
No

Hi!

I wrote a webmin module a while back, and loaded it
into the latest webmin. It messed up webmin, by
reducing the number of icons at
the top to just "servers" and "other", and removing the
names from all the icons in the new "other" page, which
happens to be every module except for mine.

I tracked it down to module.info in my module's
directory.

When my module.info looks like this:
-----
name=MyProFTPd
category=servers
desc=My ProFTPd Server
-----
then the bug occurs when I install my package from a
wbm file.

I changed it to look like this:
-----
name=MyProFTPd
category=servers
desc=My ProFTPd Server
depends=0.980
version=0.980
-----
then the installation goes well, and no menus are
messed up.

I'm not sure whether 'depends' or 'version' is the
vital line, but it
would be cool if webmin could detect and avoid this
problem. It could either refuse to install the module,
or add a couple of bogus lines to the info file, or
whatever you feel would be the right thing to do.

Discussion

  • Logged In: NO

    OOOOPS.

    Actually, the problem is that the
    /etc/webmin/module.infos.cache gets converted into one line
    per module, instead of multiple lines per module.

    And it doesn't happen on installation, it happens if I go
    into my module.

    Apparently, I changed the field separator and didn't change
    it back when I was done.

    Sorry about that!

    Mind you, it worked fine way back when I developed my
    module; is webmin more fragile now?

     
  • Logged In: NO

    That's the "$/" variable, I mean.

     
  • Logged In: NO

    By field separator I mean '$/'.

    That's what I changed and assumed was formerly "".
    $/=undef;
    $file=<IN>;
    $/="";

     
  • Jamie Cameron
    Jamie Cameron
    2002-06-26

    Logged In: YES
    user_id=129364

    Looks like this one is solved then :-)

     
  • Jamie Cameron
    Jamie Cameron
    2002-06-26

    • status: open --> closed
     
  • Logged In: NO

    Well, yes, it's fixed, but only for my module.

    It could still bite someone in the future, couldn't it?

    "Be strict in what you produce, and lenient in what you
    accept"?

     
  • Jamie Cameron
    Jamie Cameron
    2002-06-26

    Logged In: YES
    user_id=129364

    True, but there are so many perl global variables that could
    be changed
    to break webmin library code that I could never catch them
    all. In this
    case, every function that dealt with files would have to
    explicitly set $/
    in case the caller had changed it ..

     
  • Logged In: NO

    It's a tough problem, all right.

    Isolating the modules from the library code would be the way
    to go, but the only way to do that reliably is with fork and
    pipes, I think.

    Then there's the possibility of getting as much done before
    the modules get control. Cache-building, for instance, can
    be run very early.

    And finally, there's "defense in depth"; checking the data
    passed to make sure it's sane, detecting file corruption,
    etc, etc.

    I don't know what you ought to do. All I know is that
    webmin/usermin is security-critical software, and bugs are
    bad.

     
  • Jamie Cameron
    Jamie Cameron
    2002-06-28

    Logged In: YES
    user_id=129364

    Since the module.infos.cache file is so important, I will
    add code to
    prevent this specific kind of problem from happening in
    future .. Most
    other bugs that would be caused by changing $/ and other
    global perl
    variables would effect only the calling script, not the
    entire of webmin.