1. Forum
  2. Usenet
  3. LINUX.DEBIAN.BUGS.DIST

  • Bug#1107154: /usr/share/perl5/PgCommon.pm: Newer perl breaks postgresql

    From =?utf-8?q?Uwe_Kleine-K=C3=B6nig?=@21:1/5 to All on Mon Jun 2 14:50:01 2025
    Package: postgresql-client-common
    Version: 248
    Severity: normal
    File: /usr/share/perl5/PgCommon.pm
    X-Debbugs-Cc: ukleinek@debian.org

    Hello,

    after upgrading this mixed stable/testing system postgresql@15-main
    failed to start with:

    Jun 02 13:00:31 sleazy systemd[1]: Starting postgresql@15-main.service - PostgreSQL Cluster 15-main...
    Jun 02 13:00:32 sleazy postgresql@15-main[5018]: Insecure directory in $ENV{PATH} while running with -T switch at /usr/share/perl5/PgCommon.pm line 1276.
    Jun 02 13:00:32 sleazy systemd[1]: postgresql@15-main.service: Can't open PID file '/run/postgresql/15-main.pid' (yet?) after start: No such file or directory
    Jun 02 13:00:32 sleazy systemd[1]: postgresql@15-main.service: Failed with result 'protocol'.
    Jun 02 13:00:32 sleazy systemd[1]: Failed to start postgresql@15-main.service - PostgreSQL Cluster 15-main.

    The problem is the following sequence in /usr/share/perl5/PgCommon.pm:

    $ENV{'PATH'} = ''; # part of prepare_exec
    my $groups = "$gid " . `/usr/bin/id -G $uname`;

    and it's indeed bad because this seems to be interpreted as PATH=".". On
    a Debian 12 system (here: people.d.o):

    ukleinek@paradis:~$ echo "echo tralala" > tra
    ukleinek@paradis:~$ chmod u+x tra
    ukleinek@paradis:~$ perl -T -e '$ENV{"PATH"} = ""; print(`tra`);'
    tralala

    The fix is https://salsa.debian.org/postgresql/postgresql-common/-/commit/653530a168ea8124b0bfd9ffca0bbfd1acc2d1cd .

    While this is fixed for Debian 13, Debian 12 is broken in this regard.
    (Well postgresql only fails to start with a newer perl, but having "."
    in PATH is worth fixing, too.)

    I'm unsure if this justifies a higher severity than normal. I suggest to
    fix it for stable quickly before someone comes up with a way to exploit
    it :-)

    Best regards
    Uwe

    -- System Information:
    Debian Release: 13.0
    APT prefers stable-security
    APT policy: (700, 'stable-security'), (700, 'stable-debug'), (700, 'stable'), (650, 'testing-debug'), (650, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (1, 'experimental')
    Architecture: arm64 (aarch64)

    Kernel: Linux 6.12.27-arm64 (SMP w/4 CPU threads)
    Kernel taint flags: TAINT_CRAP
    Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set
    Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages postgresql-client-common depends on:
    ii netbase 6.4
    ii perl 5.40.1-3

    postgresql-client-common recommends no packages.

    postgresql-client-common suggests no packages.

    -- no debconf information

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Christoph Berg@21:1/5 to All on Mon Jun 2 16:40:01 2025
    Control: tag -1 security

    Security team, I'm unsure if that warrants a security update?

    I could instead do a stable update, but then there's the extra
    question if that's in time before the trixie release to avoid the
    functional problem.

    Re: Uwe Kleine-König
    Package: postgresql-client-common
    Version: 248
    Severity: normal
    File: /usr/share/perl5/PgCommon.pm
    X-Debbugs-Cc: ukleinek@debian.org

    Hello,

    after upgrading this mixed stable/testing system postgresql@15-main
    failed to start with:

    Jun 02 13:00:31 sleazy systemd[1]: Starting postgresql@15-main.service - PostgreSQL Cluster 15-main...
    Jun 02 13:00:32 sleazy postgresql@15-main[5018]: Insecure directory in $ENV{PATH} while running with -T switch at /usr/share/perl5/PgCommon.pm line 1276.
    Jun 02 13:00:32 sleazy systemd[1]: postgresql@15-main.service: Can't open PID file '/run/postgresql/15-main.pid' (yet?) after start: No such file or directory
    Jun 02 13:00:32 sleazy systemd[1]: postgresql@15-main.service: Failed with result 'protocol'.
    Jun 02 13:00:32 sleazy systemd[1]: Failed to start postgresql@15-main.service - PostgreSQL Cluster 15-main.

    The problem is the following sequence in /usr/share/perl5/PgCommon.pm:

    $ENV{'PATH'} = ''; # part of prepare_exec
    my $groups = "$gid " . `/usr/bin/id -G $uname`;

    and it's indeed bad because this seems to be interpreted as PATH=".". On
    a Debian 12 system (here: people.d.o):

    ukleinek@paradis:~$ echo "echo tralala" > tra
    ukleinek@paradis:~$ chmod u+x tra
    ukleinek@paradis:~$ perl -T -e '$ENV{"PATH"} = ""; print(`tra`);'
    tralala

    The fix is https://salsa.debian.org/postgresql/postgresql-common/-/commit/653530a168ea8124b0bfd9ffca0bbfd1acc2d1cd .

    While this is fixed for Debian 13, Debian 12 is broken in this regard.
    (Well postgresql only fails to start with a newer perl, but having "."
    in PATH is worth fixing, too.)

    I'm unsure if this justifies a higher severity than normal. I suggest to
    fix it for stable quickly before someone comes up with a way to exploit
    it :-)

    Best regards
    Uwe

    -- System Information:
    Debian Release: 13.0
    APT prefers stable-security
    APT policy: (700, 'stable-security'), (700, 'stable-debug'), (700, 'stable'), (650, 'testing-debug'), (650, 'testing'), (600, 'unstable'), (500, 'unstable-debug'), (1, 'experimental')
    Architecture: arm64 (aarch64)

    Kernel: Linux 6.12.27-arm64 (SMP w/4 CPU threads)
    Kernel taint flags: TAINT_CRAP
    Locale: LANG=C.UTF-8, LC_CTYPE=C.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash
    Init: systemd (via /run/systemd/system)
    LSM: AppArmor: enabled

    Versions of packages postgresql-client-common depends on:
    ii netbase 6.4
    ii perl 5.40.1-3

    postgresql-client-common recommends no packages.

    postgresql-client-common suggests no packages.

    -- no debconf information


    Christoph

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Salvatore Bonaccorso@21:1/5 to Christoph Berg on Tue Jun 3 23:20:01 2025
    Hi Christoph, hi Uwe,

    On Mon, Jun 02, 2025 at 04:25:49PM +0200, Christoph Berg wrote:
    Control: tag -1 security

    Security team, I'm unsure if that warrants a security update?

    I could instead do a stable update, but then there's the extra
    question if that's in time before the trixie release to avoid the
    functional problem.

    For reference documenting the outcome of a IRC conversation in this
    buglog: An update via the point release for bookworm (with maybe the
    option to release an update earlier via a SUA and -updates seems fine,
    can you ask this as well to the SRM?).

    While there is an issue as found by Uwe, in context of the systemd
    units the current working directory would be /, and

    [12:24] < Myon> ukleinek: most of the pg_*cluster programs chdir / before calling it, and chuid to the target user,
    so it's likely hard to exploit. pg_{backup,restore}cluster being the ones with more potential I think

    (Note worstcase if the SUA option is not accepted and no point release
    happens before the trixie release we can then still ask release team
    to reject the upload and have it go through bookworm-security for
    addressing it's . in PATH security aspect).

    Regards,
    Salvatore

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)