[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#863295: grr: Please remove dependency on prelink



Dear Geoffrey,

thanks for your email.

> I'm the current maintainer of prelink in Debian. The tool is pretty
> unloved upstream -- Fedora, where I get sources from, has removed it
> entirely in Fedora 23, and the latest release tarball isn't even in the
> usual place -- so there's a decent chance that prelink will leave Debian
> at some point in the next release cycle.

While it's indeed sad that upstream's support is in decline, that's good
to know.

> It looks like grr only uses prelink to un-prelink things, and that
> entire code is conditional on whether /usr/sbin/prelink exists. If I'm
> reading this right, that means there's no need to install prelink on the
> machines of people who install grr -- no binaries on their machines will
> be prelinked, so there's no need to un-prelink anything. So prelink
> doesn't need to be a dependency: grr will do the right thing if it's
> installed, but will skip over that code if it's not.

Taking a closer look at the code, it seems that un-prelinking is done
during the post-installation step of customizing (i.e. patching) a set
of binary templates (e.g. from [1]) which are later to be deployed to
GRR clients via the server.
The problem here is that, in case 'prelink' cannot be executed for a
binary, the binary in question will be skipped completely and will not
be available from the GRR server. During my test in a amd64 stretch VM,
this was -- at least -- happening to the Linux RPM templates. So if
prelink is not available during runtime (in particular during the time
'grr_config_updater initialize' is run) then client binaries for some
platforms WILL be missing in the GRR installation.

It would be interesting to see whether this un-prelinking is actually
necessary. The relevant code in grr/lib/build.py states that:

  # Undo all prelinking for libs or the rpm might have checksum
  # mismatches.

but it would need some more testing to see if and how this would impact
regular use. Any suggestions?

Cheers
Sascha

[1] https://packages.debian.org/sid/utils/grr-client-templates

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.alioth.debian.org/pipermail/forensics-devel/attachments/20170529/72b48377/attachment.sig>


Reply to: