[`acond`] Encountered `gosu` issues when enable `postgreSQL`

[billionairiam]

The entrypoint script for postgreSQL runs the command exec gosu postgres "$BASH_SOURCE" "$@", resulting in the error message: error: failed switching to "postgres": invalid argument.

The /etc/passwd file in the PostgreSQL Docker container contains the following entries:

root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin:x:2:2:bin:/bin:/usr/sbin/nologin
sys:x:3:3:sys:/dev:/usr/sbin/nologin
sync:x:4:65534:sync:/bin:/bin/sync
games:x:5:60:games:/usr/games:/usr/sbin/nologin
man:x:6:12:man:/var/cache/man:/usr/sbin/nologin
lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin
mail:x:8:8:mail:/var/mail:/usr/sbin/nologin
news:x:9:9:news:/var/spool/news:/usr/sbin/nologin
uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin
proxy:x:13:13:proxy:/bin:/usr/sbin/nologin
www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin
backup:x:34:34:backup:/var/backups:/usr/sbin/nologin
list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin
irc:x:39:39:ircd:/run/ircd:/usr/sbin/nologin
_apt:x:42:65534::/nonexistent:/usr/sbin/nologin
nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin
postgres:x:999:999::/var/lib/postgresql:/bin/bash

Additionally, the user ID 999 has been added to the JSON file.

Running either exec gosu postgres:postgres "$BASH_SOURCE" "$@" or exec gosu 999:999 "$BASH_SOURCE" "$@" would resolve the issue, but these commands would modify the scripts. It appears that gosu might interpret the first command as an attempt to switch to a user named "postgres" without specifying a group.

[xiangquanliu]

As we can see, user postgress belongs to 999(postgres) and 101(ssl-cert).

# id postgres
uid=999(postgres) gid=999(postgres) groups=999(postgres),101(ssl-cert)

And command gosu will invoke the syscall of setgroups with parameter 101. In this case, the error will be "invalid argument". So, it seems the supplementary gids also need to be written to /proc/[pid]/gid_map. (see https://man7.org/linux/man-pages/man7/user_namespaces.7.html)

[billionairiam]

The /etc/passwd file

Seems there is not an ssl-cert user inside the /etc/passwd file.

[xiangquanliu]

The /etc/passwd file

Seems there is not an ssl-cert user inside the /etc/passwd file.

It is a kind of group. So pls find it in /etc/group.

[billionairiam]

The /etc/passwd file

Seems there is not an ssl-cert user inside the /etc/passwd file.

It is a kind of group. So pls find it in /etc/group.

Add 101 to gid_map can fix this?

[xiangquanliu]

The /etc/passwd file

Seems there is not an ssl-cert user inside the /etc/passwd file.

It is a kind of group. So pls find it in /etc/group.

Add 101 to gid_map can fix this?

The /proc/pid/setgroups file The /proc/pid/setgroups file displays the string "allow" if processes in the user namespace that contains the process pid are permitted to employ the setgroups(2) system call; it displays "deny" if setgroups(2) is not permitted in that user namespace. Note that regardless of the value in the /proc/pid/setgroups file (and regardless of the process's capabilities), calls to setgroups(2) are also not permitted if /proc/pid/gid_map has not yet been set.

From the user_namespace manual, it does but I haven't tried it. Let's have a discussion in the weekly meeting first.

[binxing]

Linux distinguish UID and GID but to simplify implementation, ACON Image spec doesn't employ separate fields for UIDs and GIDs. Instead, all IDs listed in uids will be enabled as both UIDs and GIDs. So for this test case, what's needed is simply to add 101 to uids in the image manifest.

[billionairiam]

Linux distinguish UID and GID but to simplify implementation, ACON Image spec doesn't employ separate fields for UIDs and GIDs. Instead, all IDs listed in uids will be enabled as both UIDs and GIDs. So for this test case, what's needed is simply to add 101 to uids in the image manifest.

Solved and added PostgreSQL to action