make-ssl-cert fails if HOME is unset or empty

Bug #250400 reported by goto on 2008-07-21
50
Affects Status Importance Assigned to Milestone
ssl-cert (Ubuntu)
High
Unassigned
Hardy
High
Colin Watson
Intrepid
High
Unassigned

Bug Description

Binary package hint: ssl-cert

don't know

ProblemType: Package
Architecture: i386
Date: Mon Jul 21 03:54:21 2008
DistroRelease: Ubuntu 8.04
ErrorMessage:
 ErrorMessage: Unterprozess post-installation script gab den Fehlerwert 1 zurück
Package: ssl-cert 1.0.14-0ubuntu2.1
PackageArchitecture: all
SourcePackage: ssl-cert
Title: package ssl-cert 1.0.14-0ubuntu2.1 failed to install/upgrade:
Uname: Linux 2.6.22-14-generic i686

goto (gotolaunchpad) wrote :

That's because ssl-cert 1.0.14-0ubuntu2.1 fails to install:

Richte ssl-cert ein (1.0.14-0ubuntu2.1) ...
dpkg: Fehler beim Bearbeiten von ssl-cert (--configure):
 Unterprozess post-installation script gab den Fehlerwert 1 zurück

Changed in ssl-cert:
status: New → Confirmed
Changed in ssl-cert:
importance: Undecided → High
status: Confirmed → Triaged
stiV (stefan-wehinger) wrote :

It fails in an automatic upgrade/installation environment because the PATH variables are different than if you're using a shell. /usr/sbin is not included if a cron runs the upgrade (or installation) - therefor the command "make-ssl-cert" fails to create the files (because the file is not executed) and then the "chmod" and "chgrp" fail because there is no file to modify and exit with code 1.
you could either change the PATH envorinment variable for cron OR adapt the script so it doesn't fail (should have absolute paths anyway!!!)

it's two times in the postinstallation script [line 32 and line 40]

if the path gets changed to an absolute one, everything works as expected (i tested this)

line 32 old:
make-ssl-cert generate-default-snakeoil --force-overwrite

line 32 new:
/usr/sbin/make-ssl-cert generate-default-snakeoil --force-overwrite

line 40 old:
make-ssl-cert generate-default-snakeoil

line 40 new:
/usr/sbin/make-ssl-cert generate-default-snakeoil

thats it ...! could be closed pretty easy and fast
also affects feisty version 1.0.13 --> same problem!
i haven't looked at the intrepid version of the postinst script, but i suspect the problem could be there too - worth a look ;)

Steve Beattie (sbeattie) wrote :

Per discussion with james_w on IRC, it's a reasonable expectation for shells invoking dpkg to have /sbin and /usr/sbin in their path (for example, openssl will fail to install in the preconfiguration stage if the path does not include /sbin and /usr/sbin). Marking this as invalid. Please re-open if it turns out to not be a PATH related issue. Thanks!

Changed in ssl-cert:
status: Triaged → Invalid
status: Invalid → Won't Fix
status: Invalid → Triaged
stiV (stefan-wehinger) wrote :

well ... i am sorry - it seems i have made an error here. I don't know exactly what i did wrong but i retested everything and fixing the path is not enough.

the real problem is the ssleay.cnf that is being used to generate the standard pem file
it sets the RANDFILE variable to $ENV::HOME/.rnd

if the script is used via cron or anyother script that is being started automatically the user may still be "root", but the homedir is not set (i don't think that THIS is an error) and the creation of the file fails. If executed in a shell it works. changing the RANDFILE to /tmp/.rnd does the trick. i don't see the point why this file needs to be in the homedir of the user that installs the package or uses make-ssl-cert. isn't /tmp good enough?

[this needs reopening]

James Westby (james-w) wrote :

Hi,

/tmp is a really bad idea and a security hole, if the name .rnd is
used at least.

I think having it shared between users would perhaps be a security
hole as well.

Having it use a proper tmpfile may be possible, but it may still be at
risk.

I'm not sure the file is required though, so it may be possible to not
fail if the file can't be created, I'm not sure.

Thanks,

James

stiV (stefan-wehinger) wrote :

well you can try ... if used in an environment where there is no homedir set it does fail - no certificate is created or updated.

Changed in ssl-cert:
status: Won't Fix → New
stiV (stefan-wehinger) wrote :

this has an effect on all packages (eg. lighttpd) that use a ssleay.cnf and may create or update certificates upon installation/upgrade

Colin Watson (cjwatson) wrote :

Perhaps something like this somewhere in make-ssl-cert:

  if [ ! -d "$HOME" ]; then
      temphome="$(mktemp -d)"
      cleanup () {
          rm -rf "$temphome"
      }
      trap cleanup EXIT HUP INT QUIT TERM
      export HOME="$temphome"
  fi

Changed in ssl-cert:
status: New → Triaged
Colin Watson (cjwatson) wrote :

Ah, on investigation I've found that this is already fixed in Intrepid:

ssl-cert (1.0.16) unstable; urgency=low

  * Get rid of RANDFILE and just use /dev/urandom instead. Closes: #465279
  * Update Swedish translation. Closes: #446258
  * Update Brazilian translation. Closes: #448511
  * Add Japanese translation. Closes: #465679

 -- Tollef Fog Heen <email address hidden> Wed, 20 Feb 2008 13:27:11 +0100

-RANDFILE = $ENV::HOME/.rnd
+RANDFILE = /dev/urandom

I've provisionally marked this as a target to fix in Ubuntu 8.04.2.

Changed in ssl-cert:
importance: Undecided → High
milestone: none → ubuntu-8.04.2
status: New → Triaged
status: Triaged → Fix Released
stiV (stefan-wehinger) wrote :

if the make-ssl-cert script does not get changed this needs to be checked on other packages too (so they use /dev/urandom and not the homedir)

for the moment i think apache2 has a ssleay.cnf which uses the homedir

Colin Watson (cjwatson) on 2009-01-14
Changed in ssl-cert:
assignee: nobody → kamion
milestone: ubuntu-8.04.2 → ubuntu-8.04.3
Steve Beattie (sbeattie) wrote :

Colin, I was able to manually reproduce the bug by running:

   sudo sh -c "unset HOME ; /usr/share/debconf/frontend sh -ex /usr/sbin/make-ssl-cert generate-default-snakeoil --force-overwrite"

If you remove the redirection of stderr to /dev/null from the openssl invocation in make-ssl-cert, you'll see openssl's cryptic failure message where it complains about the variable not having a value:

  error on line 5 of /tmp/tmp.JOuWS24408
  24410:error:0E065068:configuration file routines:STR_COPY:variable has no value:conf_def.c:629:line 5

Hope this helps.

Rolf Leggewie (r0lf) wrote :

Hardy has seen the end of its life and is no longer receiving any updates. Marking the Hardy task for this ticket as "Won't Fix".

Changed in ssl-cert (Ubuntu Hardy):
status: Triaged → Won't Fix
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers