Thread: Errors installing/updating postgresql when /tmp has noexec

Errors installing/updating postgresql when /tmp has noexec

From
Don Seiler
Date:
After some recent system hardening, I'm now getting these errors when running apt to update our PGDG postgresql packages. In this case we are running postgresql-15 on Ubuntu 22.04 LTS.

Preconfiguring packages ...
Can't exec "/tmp/postgresql-15.config.rOsJHJ": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178. open2: exec of /tmp/postgresql-15.config.rOsJHJ configure 15.8-1.pgdg22.04+1 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

This doesn't cause the install the fail though, and postgresql gets updated to 15.12 and starts up just fine. It's not clear to me if there is now some danger/flaw in my installation or if this is something that can be ignored.

It doesn't appear that I can just set an environment variable like TMP, TEMP, TEMPDIR etc to change this. I see that it can be changed via an apt config change[1].

However, I'm wondering if this is something that's better changed in the packaging. Setting noexec on /tmp (and /var) is a standard CIS/DISA security requirement now.


--
Don Seiler
www.seiler.us

Re: Errors installing/updating postgresql when /tmp has noexec

From
Don Seiler
Date:

On Tue, Apr 8, 2025 at 12:21 PM Don Seiler <don@seiler.us> wrote:
After some recent system hardening, I'm now getting these errors when running apt to update our PGDG postgresql packages. In this case we are running postgresql-15 on Ubuntu 22.04 LTS.

Preconfiguring packages ...
Can't exec "/tmp/postgresql-15.config.rOsJHJ": Permission denied at /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178. open2: exec of /tmp/postgresql-15.config.rOsJHJ configure 15.8-1.pgdg22.04+1 failed: Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

This doesn't cause the install the fail though, and postgresql gets updated to 15.12 and starts up just fine. It's not clear to me if there is now some danger/flaw in my installation or if this is something that can be ignored.

It doesn't appear that I can just set an environment variable like TMP, TEMP, TEMPDIR etc to change this. I see that it can be changed via an apt config change[1].

However, I'm wondering if this is something that's better changed in the packaging. Setting noexec on /tmp (and /var) is a standard CIS/DISA security requirement now.


For what it's worth, setting this apt config to specify a non-/tmp path works around the problem:

$ cat /etc/apt/apt.conf.d/99tempdir.conf
APT::ExtractTemplates::TempDir "/some/other/tmp";

However it seems like we still shouldn't be trying to exec from /tmp by default either. In the meantime we'll see how best to quickly deploy this workaround to our fleet of machines.

Don.

--
Don Seiler
www.seiler.us

Re: Errors installing/updating postgresql when /tmp has noexec

From
Christoph Berg
Date:
Re: Don Seiler
> > Preconfiguring packages ...
> > Can't exec "/tmp/postgresql-15.config.rOsJHJ": Permission denied at
> > /usr/lib/x86_64-linux-gnu/perl-base/IPC/Open3.pm line 178. open2: exec of
> > /tmp/postgresql-15.config.rOsJHJ configure 15.8-1.pgdg22.04+1 failed:
> > Permission denied at /usr/share/perl5/Debconf/ConfModule.pm line 59.

This is failing in debconf, a standard Debian tool.

> > However, I'm wondering if this is something that's better changed in the
> > packaging. Setting noexec on /tmp (and /var) is a standard CIS/DISA
> > security requirement now.

TBH, I doubt that it is standard practice because this change will
make any debconf-using package explode on installation. If at all,
it's optional extra hardening above standard where extra configuration
steps are expected.

> For what it's worth, setting this apt config to specify a non-/tmp path
> works around the problem:
> 
> $ cat /etc/apt/apt.conf.d/99tempdir.conf
> APT::ExtractTemplates::TempDir "/some/other/tmp";

You will have to include this workaround on all machines.

> However it seems like we still shouldn't be trying to exec from /tmp by
> default either. In the meantime we'll see how best to quickly deploy this
> workaround to our fleet of machines.

If you want to get this supported by default, work with Debian and/or
Ubuntu to get debconf updated. But this won't fix your 22.04 Ubuntu.

Christoph