Bug#1365: minicom oddities in postinst script
Package: minicom
Version: 1.6 (2)
Firstly, Debian's minicom package is _not_ vulnerable to the
setuid-root security hole announced on linux-alert recently: our
minicom package does not install minicom setuid root.
However, while checking for this I discovered a few problems in the
postinst which are obvious even without running it.
It always prompts to ask whether to modify the termcap and .profile
files, even if they have been modified before. If you answer yes the
second time it will append the stuff *again* !
There are several problems with this:
Firstly, if the modifications were really useful it should do them
without prompting at all.
Secondly, it should spot if the modifications have already been made
and not make them again.
Thirdly, it should not modify the /etc/profile in the way that it does
(it adds code which conditionally sets a MINICOM environment variable,
depending on whether TERM=console). There is no excuse for that kind
of hack. If the problem can't be solved other than by conditionally
setting the MINICOM variable then a wrapper around minicom should do
it. Modifying the /etc/profile will (a) cause conffiles resolution
prompts which the user may not understand and (b) may not work
depending on exactly how minicom is invoked.
Fourthly, it looks for TERM=console and doesn't know about TERM=linux.
Fifthly, if the `minicom' termcap entry were appropriate it should be
in the standard /etc/termcap file, not modified by minicom.
Sixthly, using a `minicom' termcap entry like that to get special
features (the postinst appears to arrange for minicom to see a
terminal type of `minicom' when the terminal is really `console', and
then provides a termcap entry with some capabilities which appear from
the commentary to relate to colour and ANSI graphics support) is a
ridiculous hack. The `linux' termcap entry should be made to describe
the Linux console correctly and completely, and minicom should be made
to understand it properly. Eventually everything should be converted
to use terminfo.
Seventhly, the script doesn't check for errors when appending to the
files, because it doesn't use `set -e' (though even if it did it
wouldn't help for the moment because bash's builtin echo doesn't
return a non-zero exit status when it gets a write error).
Ian.
Reply to: