Bug#884964: using "su - " in postinst causing some installs to fail
Package: debconf-doc Version: 1.5.61 The use of "su - " in postinst is breaking package installs/upgrades only when there are file(s) in /etc/profile.d. Details are in the two bug reports: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884955 https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=875958 I do not know what other packages may use "su - " but would suggest that this issue be documented in debconf-doc so maintainers/devs can avoid this. If I should file this some place else, please let me know. Thank you. -- Terry LinuxChix System Admins
Bug#884964: using "su - " in postinst causing some installs to fail
Simon,
Thank you for your comments.
> Arguably the bug here is that there was a file in /etc/profile.d that
> assumed bash syntax, rather than guarding bashisms with a check for
> $BASH_VERSION or similar. I would recommend changing those profile
> snippets so the problematic parts only run on shells that are known to
> support them (bash and maybe zsh).
>
> For many uses of profile snippets, it would make sense to wrap them in
> a guard against non-interactive shells, which also dodges any issues
> that those snippets might cause in non-interactive shells.
>
> smcv
>
I've done quite a bit more testing on this. I've had three packages with
this issue - spamassassin, sa-compile and tuptime.
The user for spamassassin and sa-compile is debian-spamd whose shell is
set to /bin/sh. The user for tuptime is tuptime whose shell is also set
to /bin/sh.
Changing the shell to /bin/bash for tuptime for example, eliminates the
error with using 'su -'.
I did note that the package postgresql-common calls the Bourne shell in
postinst but without a login and this poses no problem during installation:
su -s /bin/sh postgres -c "test -O /var/lib/postgresql &&
test -G /var/lib/postgresql" || \
chown postgres:postgres /var/lib/postgresql
The postgres user's shell is /bin/bash but I don't think this matters
because login isn't being used so /etc/profile.d files aren't being read.
Aliases present no problem. Functions, depending on how they are
written, do.
function somefunction () {} causes a problem.
function somefunction {} causes a problem.
somefunction () {} does not. So there's the bashism - using the
reserved word 'function'.
Interestingly, when using the reserved word function, the presence of ()
changes the error message.
With the use of ():
-sh: 5: /etc/profile.d/test.sh: Syntax error: "(" unexpected (expecting
"fi")
Without the use of ():
-sh: 5: /etc/profile.d/test.sh: function: not found
Definitely would have been much easier to spot the error had we not used ().
Wrapping the function with this worked.
if [ "${BASH-}" ] && [ "$BASH" != "/bin/sh" ]; then
function testfunction
{
echo 'Function from test.sh in /etc/profile.d'
}
fi
Doing the same thing but with the () included did not work. That has me
scratching my head. It should have bypassed those lines entirely.
I'll update the bug reports I've filed in the packages with this
information. I'm not sure there's a good solution for this. It seems to
be such a specific issue. Had I not created a user with a /bin/sh shell
and tried to recreate the function for that user, I'm not sure I would
have twigged that the reserved word function was causing the problem
since the error kept coming back as the ( causing the issue.
Anyway, thanks again for your comments. It spurred me to investigate
further.
--
Terry
Bug#884964: Bug#875958: sa-compile: The package fails to run sa-compile
An update.
We experienced the same problem with the package tuptime and I filed a
bug report there[1]. I had some comments from the other bug reports
which led me to do some more testing. Here's what I found.
Three packages have had this issue - spamassassin, sa-compile and tuptime.
The user for spamassassin and sa-compile is debian-spamd whose shell is
set to /bin/sh. The user for tuptime is tuptime whose shell is also set
to /bin/sh. No other users on my system use /bin/sh.
Changing the shell to /bin/bash for tuptime for example, eliminates the
error with using 'su -'.
The aliases in the /etc/profile.d files present no problem. Functions,
depending on how they are written, do.
function somefunction () {} causes a problem.
function somefunction {} causes a problem.
somefunction () {} does not. Using the reserved word 'function'
causes /bin/sh to throw an error. Interestingly, when using the reserved
word function, the presence of () changes the error message.
With the use of ():
-sh: 5: /etc/profile.d/test.sh: Syntax error: "(" unexpected (expecting
"fi")
Without the use of ():
-sh: 5: /etc/profile.d/test.sh: function: not found
Definitely would have been much easier to spot the error had we not used ().
So while calling a login shell caused a problem, ultimately, it's
because /bin/sh does not recognise the reserved word 'function'. I'm not
sure there's a good solution for this. It seems to be such a specific
issue. Had I not created a user with a /bin/sh shell and tried to
recreate the function for that user, I'm not sure I would have twigged
that the reserved word function was causing the problem since the error
kept coming back as the "(" causing the issue. At least you're aware if
this is ever reported again.
I hope this provides some clarification and allows you to reproduce the
issue.
In testing, four things fixed the issue:
1. Setting a user's shell to /bin/bash.
2. Using su without "-"
3. removing the reserved word function from the function
4. Wrapping the function with a test for bash but it behaved strangely.
It worked if no "()" was present but if it was present, we had an error.
Unexpected. We're still testing.
We've chosen to remove the reserved word function so now our functions
are simply somefunction () which solves the issue for us.
Thank you.
--
Terry
LinuxChix System Admins
[1] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=884955
Bug#884964: using "su - " in postinst causing some installs to fail
Thank you again, Simon, for your concise explanations. We do have a policy on shell usage and the snippets were tested against those shells, but not against /bin/sh. My fault, I'm afraid, since I hadn't considered system users. We'll be adding that to our policy. I've sent the info to the two packages I filed bug reports for. Hopefully, the next time someone runs into the issue, they'll be able to come across these discussions and resolve it quickly. -- Terry
Bug#875958: sa-compile: The package fails to run sa-compile
The problem seems to occur only if you have script(s) in /etc/profile.d.
On the last upgrade to 9.3 Stretch, we experienced this issue. Also, see
comment by Vagnerr at
https://askubuntu.com/questions/422264/how-to-debug-dpkg-configure-error-in-subprocess-post-installation
describing this problem from May 2015.
"I had a similar issue to you. With the installer just flat failing.
Mine turned out to be an issue with installing the latest version from
debian-backports for wheezy. It turned out that they changed the post
install script to have a 'su - $OWNER -c "sa-update ...' call which did
a full login shell exec to /bin/sh which was incompatible with our
/etc/profile and /etc/profile.d files. removing the '-' making it "su
$OWNER -c " fixed it for me – Vagnerr May 16 '15 at 14:43"
I can confirm that removal of the file in /etc/profile.d fixed the problem.
The file in question is /var/lib/dpkg/info/sa-compile.postinst, line 10,
which reads:
su - $OWNER -c "sa-compile --quiet"
Here is the relevant portion of the transcript from our upgrade
highlighting the issue with /etc/profile.d.
Setting up spamassassin (3.4.1-6+deb9u1) ...
Installing new version of config file /etc/cron.daily/spamassassin ...
Installing new version of config file /etc/spamassassin/65_debian.cf ...
-su: 19: /etc/profile.d/lcx_all_users_aliases.sh: Syntax error: "("
unexpected
dpkg: error processing package spamassassin (--configure):
subprocess installed post-installation script returned error exit status 2
Setting up zsh (5.3.1-4+b2) ...
Setting up libicu57:amd64 (57.1-6+deb9u1) ...
Setting up iproute2 (4.9.0-1+deb9u1) ...
Setting up linux-image-4.9.0-4-amd64 (4.9.65-3) ...
/etc/kernel/postinst.d/initramfs-tools:
update-initramfs: Generating /boot/initrd.img-4.9.0-4-amd64
W: initramfs-tools configuration sets
RESUME=UUID=e4df7c74-843d-4e43-a7de-8c97d1469f24
W: but no matching swap device is available.
I: The initramfs will attempt to resume from /dev/vda2
I: (UUID=bf035740-4836-4088-835d-84bd43a5cd05)
I: Set the RESUME variable to override this.
/etc/kernel/postinst.d/zz-update-grub:
Generating grub configuration file ...
Found linux image: /boot/vmlinuz-4.9.0-4-amd64
Found initrd image: /boot/initrd.img-4.9.0-4-amd64
Found linux image: /boot/vmlinuz-4.9.0-3-amd64
Found initrd image: /boot/initrd.img-4.9.0-3-amd64
done
Processing triggers for libc-bin (2.24-11+deb9u1) ...
dpkg: dependency problems prevent configuration of sa-compile:
sa-compile depends on spamassassin; however:
Package spamassassin is not configured yet.
dpkg: error processing package sa-compile (--configure):
dependency problems - leaving unconfigured
Processing triggers for systemd (232-25+deb9u1) ...
Setting up libsqlite3-0:amd64 (3.16.2-5+deb9u1) ...
Processing triggers for man-db (2.7.6.1-2) ...
Setting up libpython2.7-minimal:amd64 (2.7.13-2+deb9u2) ...
Setting up openssh-client (1:7.4p1-10+deb9u2) ...
Setting up spamc (3.4.1-6+deb9u1) ...
Setting up libpython2.7-stdlib:amd64 (2.7.13-2+deb9u2) ...
Setting up libdbus-1-3:amd64 (1.10.24-0+deb9u1) ...
Setting up python2.7-minimal (2.7.13-2+deb9u2) ...
Setting up iproute (1:4.9.0-1+deb9u1) ...
Setting up python2.7 (2.7.13-2+deb9u2) ...
Setting up openssh-sftp-server (1:7.4p1-10+deb9u2) ...
Setting up libpython2.7:amd64 (2.7.13-2+deb9u2) ...
Setting up libpython2.7-dev:amd64 (2.7.13-2+deb9u2) ...
Setting up dbus (1.10.24-0+deb9u1) ...
A reboot is required to replace the running dbus-daemon.
Please reboot the system when convenient.
Setting up python2.7-dev (2.7.13-2+deb9u2) ...
Setting up openssh-server (1:7.4p1-10+deb9u2) ...
Processing triggers for libc-bin (2.24-11+deb9u1) ...
Errors were encountered while processing:
spamassassin
sa-compile
--
Terry
LinuxChix System Admins
