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

libnids, autolog and snoopy (Was: Re: Ask for review)



Hi Marcos and Rapha?l,

from this thread three packages are still open.  I looked at them:


1. libnids

I reverted the soname bump as suggested by Rapha?l and bumped the
Standards version to 4.0.0

Rapha?l also requested that we ensure that the dsniff version in the
archive works with the updated libnids.  I have not done that yet.
(Working on snoopy took me too long and it's too late now?)


2. autolog

I see that Marcos worked on the improvements suggested by Rapha?l.
I've made a few changes on top of it:
* changed debian/rules so that clean works also with patches unapplied
* removed preinst file: It does a cleanup of wrongly leftover files from
  that package, but the cleanup code has been present since a version
  before o-o-stable.  It's my understanding that this can now be
  dropped.  Please correct me if that's not the case.
* simplified and corrected the removal of autolog's log files
* minor beatification of postinst
* correct errors in systemd service file (and make sure it's actually
  installed?)

I have a question regarding the systemd service file.  Marcos, you
specified:

  CapabilityBoundingSet=~CAP_SYS_PTRACE

Is there a reason you just remove that specific capability?  I expect
there are a lot more that could be removed and I was wondering why you
exactly remove that one.


3. snoopy

Rapha?l, you wrote:
> 
>     # is snoopy already in $PRELOADFILE?
>     test -f $PRELOAD && grep "$LIBNAME" $PRELOAD && exit 0
> 
> That will fail if $PRELOAD does not exist or if it doesn't contain
> $LIBNAME. Given "set -e" the whole postinst will fail... and thus
> dpkg-reconfigure will never work to add or remove libsnoopy.so from
> /etc/ld.so.preload.

I don't think what you say is correct.  From dash(1) about errexit:

    If not interactive, exit immediately if any untested command fails.
    The exit status of a command is considered to be explicitly tested
    if the command is used to control an if, elif, while, or until; or
    if the command is the left hand operand of an ?&&? or ?||? operator.

Both the test and the grep are left hand operands of "&&" here, so I
don't see how this can fail.  However, since I dislike the `exit 0` (as
it doesn't allow the #DEBHELPER# expanded code to run later), I have
rewritten it anyways. I made all the other changes Rapha?l proposed as
well.

During testing I found out that programs with the suid bit set cannot
find the shared object unless the absolute path to the shared library
is given in /etc/ld.so.preload.  I made a little stunt to have the
DEB_HOST_MULTIARCH triplet available in postinst?

Now the package is no longer Multiarch capable.  But to be honest, it
never was, all the versions since the Multiarch was introduced have the
problem explained above.  I've removed `Multiarch: same` from
debian/control.


Regards
Lukas



Reply to: