Eduardo Moraes wrote...
> I am looking for a sponsor for my package "cid"
The packaging looks sane besides the maintainer scripts, more on that
below. However, the entire package scares me. It seems to fiddle a lot
with several config files that come from other packages (like
/etc/ntp.conf), it contains hundreds of lines of complex shell
operations that all run as root, it seems to re-implement mechanisms to
control daemon processes, including on-the-fly creation of systemd
service files, does things in an overly complex way (in Debian, once ntp
is configured, you may assume /var/lib/ntp/ exists and belongs to
ntp:ntp), and finally there is very little explanation in the code. So
I'm concerned this package might introduce a huge bunch of security
issues. Not my department, though.
The two maintainer scripts cid-base.postinst and .postrm confuse me.
They do quite many things but don't provide an explanation.
Just a few points, there might be more:
| USRLIBDIR=/usr/lib/cid
[ postinst:18 ]
This directory isn't populated by the cid-base package, and therefore
checks for files there will fail. Which makes me wonder whether major
parts of postinst are actually dead code.
| elif [ -s "/opt/cid/lib/domain.conf" ]; then
[ postinst:23 ]
cid-base doesn't ship files in /opt/, so it shouldn't probe for one in
that place (imagine somebody created that file, by accident, or even
with malicious intent).
postinst:69 defines a list of files that are copied around later. It's
more out of curiousity: What happens here, why is this done? Is the
backup used later? Is the actual e.g. /etc/group affected by this?
So, postinst leaves me in a bad feeling. I didn't thourogly check what
actually is supposed to happen but I doubt all these things have to take
place in postinst.
In postrm, you (hopefully) load the variables $SUDODIR, $PROFILEDIR
and $SYSTEMDDIR from '/var/lib/cid/databases/station.db' which is
created in postinst without these. Unless the file is modified before
the postinst run - something you cannot rely on - none of the three
variables are set, and postrm will happily purge /cid-sudo-allusers,
/cid_DomainUsersLogon.sh and perhaps /cid.service if they exist.
Also,
| [ -f "${SYSTEMDDIR}/cid.service" -a `command -v systemctl` ] && systemctl disable cid.service && rm -f "${SYSTEMDDIR}/cid.service" && systemctl daemon-reload
[ postrm:12 ]
looks a lot like a hand-crafted systemd service file handling. The tools
provided by dh_systemd are certainly the better choice.
Christoph
Attachment:
signature.asc
Description: Digital signature