Bug#1028190: marked as done (tzdata: Possible bug in postinst)
Your message dated Tue, 10 Jan 2023 22:45:14 +0000
with message-id <07e33892f1e14e01ba5517eb69f927715e726a18.camel@debian.org>
and subject line Re: tzdata: Possible bug in postinst
has caused the Debian Bug report #1028190,
regarding tzdata: Possible bug in postinst
to be marked as done.
This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.
(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)
--
1028190: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1028190
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: tzdata
Version: 2022g-1
Severity: normal
X-Debbugs-Cc: niels@thykier.net
In the postinst, there is the following snippet:
> #! /bin/sh
> set -e
> [...]
# Update the time zone
echo $AREA/$ZONE > "$DPKG_ROOT/etc/timezone"
ln -nsf /usr/share/zoneinfo/$AREA/$ZONE "$DPKG_ROOT/etc/localtime.dpkg-new" && \
mv -f "$DPKG_ROOT/etc/localtime.dpkg-new" "$DPKG_ROOT/etc/localtime"
which restorecon >/dev/null 2>&1 && restorecon "$DPKG_ROOT/etc/localtime"
I think there is a bug in the `which restorecon ...` construct that can
cause termination of the postinst rather than conditional call to
`restorecon`.
As far as I can tell, the construct will "fail" when restorecon is present:
```
which foo >/dev/null 2>&1 && foo ; echo $?
1
```
With `set -e`, this would trigger the postinst to fail and abort the
installation.
I think this case calls for a `if ...; then .. fi` construct or a `!
which ... && ...`.
I feel this ought to be an RC bug. However, given I found this with
(manual) static analysis and no one else complained, I guess this case
is basically never triggered. That is why I have reported as non-RC.
Thanks,
~Niels
--- End Message ---
--- Begin Message ---
Hi,
On Sun, 8 Jan 2023 10:22:09 +0100 Niels Thykier <niels@thykier.net>
wrote:
> Package: tzdata
> Version: 2022g-1
> Severity: normal
> X-Debbugs-Cc: niels@thykier.net
>
> In the postinst, there is the following snippet:
>
> > #! /bin/sh
> > set -e
> > [...]
> > # Update the time zone
> > echo $AREA/$ZONE > "$DPKG_ROOT/etc/timezone"
> > ln -nsf /usr/share/zoneinfo/$AREA/$ZONE
"$DPKG_ROOT/etc/localtime.dpkg-new" && \
> > mv -f "$DPKG_ROOT/etc/localtime.dpkg-new"
"$DPKG_ROOT/etc/localtime"
> > which restorecon >/dev/null 2>&1 && restorecon
"$DPKG_ROOT/etc/localtime"
> >
>
> I think there is a bug in the `which restorecon ...` construct that
can
> cause termination of the postinst rather than conditional call to
> `restorecon`.
>
> As far as I can tell, the construct will "fail" when restorecon is
present:
>
> ```
> which foo >/dev/null 2>&1 && foo ; echo $?
> 1
> ```
>
>
> With `set -e`, this would trigger the postinst to fail and abort the
> installation.
>
> I think this case calls for a `if ...; then .. fi` construct or a `!
> which ... && ...`.
Following snippet:
```
#!/bin/sh
set -e
which restorecon >/dev/null 2>&1 && echo found
echo done
```
prints always "done" and exits with 0 when run with dash, bash, zsh and
either restorecon present or not.
So the restorecon line in postinst seems to be correct.
--
Benjamin Drung
Debian & Ubuntu Developer
--- End Message ---
Reply to: