GroupWise Mobility Version 11431 WARNING: database "datasync" has a collation version mismatch CVE-2024-53908

GroupWise Mobility Version 11431 WARNING:  database "datasync" has a collation version mismatch


To the GMS and django 4.2.6 security issue CVE-2024-53908 KM Doc which Caroline Oest has posted an addition: Thanks to Caroline for the info about the CVE

The following information may appear in GroupWise Mobility version 11431 after installation

WARNING:  database "datasync" has a collation version mismatch
DETAIL:  The database was created using collation version 2.31, but the operating system provides version 2.38.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE datasync REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
WARNING:  database "datasync" has a collation version mismatch
DETAIL:  The database was created using collation version 2.31, but the operating system provides version 2.38.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE datasync REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
WARNING:  database "datasync" has a collation version mismatch

And other lines with similar messages

Solution as an example:

gms stop

systemctl status postgresql --> postgres shold running

psql -U datasync_user datasync
Password for user datasync_user:
WARNING:  database "datasync" has a collation version mismatch
DETAIL:  The database was created using collation version 2.31, but the operating system provides version 2.38.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE datasync REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
psql (16.6, server 15.10)
Type "help" for help.

datasync=>


datasync=> \l
                                                          List of databases
   Name    |     Owner     | Encoding | Locale Provider |   Collate   |    Ctype    | ICU Locale | ICU Rules |   Access privileges
-----------+---------------+----------+-----------------+-------------+-------------+------------+-----------+-----------------------
 datasync  | datasync_user | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
 dsmonitor | datasync_user | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
 mobility  | datasync_user | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
 postgres  | postgres      | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           |
 template0 | postgres      | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres          +
           |               |          |                 |             |             |            |           | postgres=CTc/postgres
 template1 | postgres      | UTF8     | libc            | en_US.UTF-8 | en_US.UTF-8 |            |           | =c/postgres          +
           |               |          |                 |             |             |            |           | postgres=CTc/postgres
(6 rows)



datasync=> ALTER DATABASE datasync    REFRESH COLLATION VERSION;
NOTICE:  changing version from 2.31 to 2.38
ALTER DATABASE
datasync=>


datasync=> ALTER DATABASE dsmonitor   REFRESH COLLATION VERSION;
NOTICE:  changing version from 2.31 to 2.38
ALTER DATABASE
datasync=>


ALTER DATABASE
datasync=> ALTER DATABASE mobility REFRESH COLLATION VERSION;
NOTICE:  changing version from 2.31 to 2.38
ALTER DATABASE
datasync=>



datasync-> \q

psql -U postgres

WARNING:  database "postgres" has a collation version mismatch
DETAIL:  The database was created using collation version 2.31, but the operating system provides version 2.38.
HINT:  Rebuild all objects in this database that use the default collation and run ALTER DATABASE postgres REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.
psql (16.6, server 15.10)
Type "help" for help.

postgres=# ALTER DATABASE postgres  REFRESH COLLATION VERSION;
NOTICE:  changing version from 2.31 to 2.38
ALTER DATABASE



If the user postgres throws an error during login in the pg_hba.conf

edit pg_hba.conf

# “local” is for Unix domain socket connections only
local all all trust
#local all postgres md5
#local all postgres peer

systemctl restart postgresql

alter database

Later change pg_hba.conf  to the original settings

systemctl restart postgresql

gms start

check gms and check sync to phones

As always, if something is wrong here, please let me know about the error

Greetings

George

“You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0  

    Great work, Georg.

    I have seen the same error(s).

    However is there any impact on functionality?


    Use "Verified Answers" if your problem/issue has been solved!

  • Verified Answer

    +1   in reply to   

    Hallo Diethmar,

    the key: REFRESH COLLATION VERSION, or build PostgreSQL with the right library version.

    Let's try to express it simply

    the error can occur if the libcx versions of the system on which the PSQL databases / table / changes / patches are installed differ from the system on which the databases / table / changes / patches are later installed. Unfortunately, this can lead to errors in the target database.

    There is more detailed information in the bug trackers, the PSQL community developers want to introduce an improvement so that no more problems occur with patches from libcx.

    The template tables also have to be converted.

    postgres=# ALTER DATABASE template0 REFRESH COLLATION VERSION;

    postgres=# ALTER DATABASE template1 REFRESH COLLATION VERSION;

    To your question:

    Yes, I found errors in the database logs before the conversion. Maybe Rob (OT)) can say more about what I have written here.


    And again the problem is clear here in the log output : right library version so this is the impact on the function of Mobility before the workaround. In my opinion, changing to the correct Libray version cannot cause a problem in Mobility

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    So I will follow your steps and fix my postgresql environment Innocent!


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to   

    Thank you for your feedback.

    glibc-2.38-150600.14.20.3.x86_64 and everything that went with it, before it was glibc-2.31 whatever

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    One more important thing. For me it is an automatism, when I am working on a PSQL and everything is finished please execute a reindex. Because a refresh of the collation version is executed here, this can have an effect on the index of the relevant DB

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0   in reply to   

    Strange ... I am sure that I had this error two days ago ...

    But I do not see any issues today. I even did a re-install of gms.iso. But no remarks or complaints ..

    There is only a small difference compared to my activity some days ago: I received some Sles patches and I did a re-index.


    Use "Verified Answers" if your problem/issue has been solved!

  • 0   in reply to   

    Hello Dithmar,

    that is the issue, the glibc has been replaced by a SLES update. With the exchange there is the error. With psql list \l you can see that the local provider for connecting to the database is the clib api. It is quite possible that the reinstallation of gms brings the same result, I would have to check this again in the lab

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei

  • 0  

    Thanks Georg for the additional info not much more to add, just to be sure as the CVE is mentioned this is the TID written for it as you mentioned 

  • 0  

    I did update to build 11433 and haven't faced collation version mismatch, looks like this is related to PostgreSQL version, I have 13.X. 

    David

  • 0   in reply to   

    Hello David,

    what you describe here for your version is correct, assuming that the Mobility runs on SELS 12. SLES 12 still uses the old “locale data”, in SLES 15 the situation is different, here a new “local data” model is used and changes in the glibc can have an effect on a Postgres application. Here is a source: wiki.postgresql.org/.../Locale_data_changes. It is also possible that the new build contains scripts that make the necessary changes as described by me above 

    The glibc topic has been known for some time, here is something “Beware of your next glibc upgrade” postgresql.verite.pro/.../glibc-upgrade.html .

    SUSE has notes here “After upgrading a PostgreSQL server to SLES 15 SP3, a REINDEX is required.” www.suse.com/.../

    The matter is actually much more complex to consider. Sometimes, as an IT specialist, you simply have to dig deeper and breathe longer to understand what's going on underneath. One more thing from the SUSE KM There are no databases affected that use “POSIX” or “C” collations. Mobilty uses en_US.UTF-8

    Maybe OT can say more about this, Postgres is used in many other OT applications.
    George

    “You can't teach a person anything, you can only help them to discover it within themselves.” Galileo Galilei