[pkg-netfilter-team] Bug#916596: iptables.postinst failure on link creation

[Andreas Henriksson]

Control: tags -1 + moreinfo

On Sun, Feb 05, 2023 at 12:08:32PM +0200, Adrian Bunk wrote:
> Control: tags -1 - moreinfo
> Control: severity -1 serious
> 
> On Fri, Dec 28, 2018 at 02:59:26PM +0100, Arturo Borrero Gonzalez wrote:
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA512
> > 
> > Control: tag -1 moreinfo
> > 
> > On Sun, 16 Dec 2018 13:14:19 +0100 Olivier <olivieraj at free.fr> wrote:
> > > Package: iptables Version: 1.8.2-2+b1 Severity: important
> > > 
> > > Dear Maintainer,
> > > 
> > > Issue occure during iptables:i386 1.8.2-2 -> 1.8.2-2+b1 upgrade.
> > > 
> > > /var/lib/dpkg/info/iptables.postinst fail with message:
> > > 
> > > ln: failed to create symbolic link ''$'\t''
> > > /sbin/iptables-save': No such file or directory
> > > 
> > 
> > I can't reproduce the issue:
> >...
> > I didn't try in i386 because I don't have any machine (virtual or
> > physical) with that arch, maybe is a architecture specific bug in the
> > shell? Hard to believe to say the least.
> >...
> 
> I can reproduce the problem in a current amd64 unstable chroot.

Great, can you provide some information regarding how?

Could you for example modify iptables.prerm to check what the content of
$IFS is when you reproduce this?
Did any other packages maintainer script (which does things with IFS)
error out while you reproduce the problem with iptables?

I can only speculate about this issue. I don't doubt the original
reportes error message actually happened and is real, but I don't see
how.
The only possibility I see is that IFS was modified to a non-default
value which made it no longer include tab- and space-characters.
The iptables.prerm script doesn't set IFS itself, so I have to assume
it somehow inherited a dirty environment from somewhere.
Is it possible that some other packages maintainerscript code messed
with IFS without resetting it and then that environment got inherited by
iptables.prerm? If so then I think the package needs to be identified
and this bug reassigned to it....
I don't think every package that has maintainerscripts should expect a
dirty environment and guard against for example a non-default IFS, but
that's kind of the only solution inside iptables that I can see.... have
it explicitly (un)set IFS. I however don't think that's the correct
solution, just a solution.

> 
> #1007829 was a similar problem in arptables,
> I haven't checked how these are related.

I don't see how these two are related at all.
#1007829 seems to be a simple logic error.

Regards,
Andreas Henriksson