libnids, autolog and snoopy (Was: Re: Ask for review)
Marcos Fouces
marcos.fouces at gmail.com
Thu Jul 6 22:02:20 UTC 2017
Hi Raphaël and Lukas
El 05/07/17 a las 23:58, Lukas Schwaighofer escribió:
> 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…)
I did rebuild and use dsniff and libnids repo versions and it seems to
works well. So i believe that libnids could be uploaded.
>
> 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.
This is a capability that i judged unnecesary as i don't think that
autolog should not help to debug any other process.
I did not remove more capacities due to lack of time to test the result.
In fact, i still not tested properly if the removal of CAP_SYS_PTRACE
affect autolog.
I believe that more test is needed in order to upload this package
> 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.
Good!
>
> 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
If you tested properly the package (basically, check that produces
proper log entries), i believe that it could be uploaded.
Good job! Thanks.
Marcos
More information about the Pkg-security-team
mailing list