script_user not inheriting supplementary groups

[anourai]

Describe the bug
script_user only runs with its primary group, not supplementary groups

To Reproduce
sudo usermod -aG example-group keepalived_script # add example-group as supplementary group

Configure "notify <path-to-notify-bash-script>"
run "id" in the above script to print group memberships
Output of id shows that only the process runs with primary group membership only, not supplementary groups

Expected behavior
I would expect the process to run with all group memberships, not just the primary group membership.

Keepalived version
2.3.3

configure options: --build=aarch64-linux-gnu --prefix=/usr --includedir=/usr/include --mandir=/usr/share/man --infodir=/usr/share/info --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir=/usr/lib/aarch64-linux-gnu --runstatedir=/run --disable-maintainer-mode --disable-dependency-tracking --enable-snmp --enable-sha1 --enable-snmp-rfcv2 --enable-snmp-rfcv3 --enable-dbus --enable-json --enable-bfd --enable-regex --enable-log-file --enable-reproducible-build --with-init=systemd build_alias=aarch64-linux-gnu CFLAGS=-g -O2 -Werror=implicit-function-declaration -ffile-prefix-map=/build/reproducible-path/keepalived-2.3.3=. -fstack-protector-strong -fstack-clash-protection -Wformat -Werror=format-security -mbranch-protection=standard LDFLAGS=-Wl,-z,relro CPPFLAGS=-Wdate-time -D_FORTIFY_SOURCE=2

Config options:  NFTABLES LVS REGEX VRRP VRRP_AUTH VRRP_VMAC JSON BFD OLD_CHKSUM_COMPAT SNMP_V3_FOR_V2 SNMP_VRRP SNMP_CHECKER SNMP_RFCV2 SNMP_RFCV3 DBUS IPROUTE_ETC_DIR=/etc/iproute2 IPROUTE_USR_DIR=/usr/share/iproute2 FILE_LOGGING LOG_FILE_APPEND INIT=systemd SYSTEMD_NOTIFY

System options:  VSYSLOG MEMFD_CREATE IPV6_FREEBIND IPV6_MULTICAST_ALL IPV4_DEVCONF LIBNL3 RTA_ENCAP RTA_EXPIRES RTA_NEWDST RTA_PREF FRA_SUPPRESS_PREFIXLEN FRA_SUPPRESS_IFGROUP FRA_TUN_ID RTAX_CC_ALGO RTAX_QUICKACK RTEXT_FILTER_SKIP_STATS FRA_L3MDEV FRA_UID_RANGE RTAX_FASTOPEN_NO_COOKIE RTA_VIA FRA_PROTOCOL FRA_IP_PROTO FRA_SPORT_RANGE FRA_DPORT_RANGE RTA_TTL_PROPAGATE IFA_FLAGS F_OFD_SETLK IFA_PROTO LWTUNNEL_ENCAP_MPLS LWTUNNEL_ENCAP_ILA NET_LINUX_IF_H_COLLISION LIBIPVS_NETLINK IPVS_DEST_ATTR_ADDR_FAMILY IPVS_SYNCD_ATTRIBUTES IPVS_64BIT_STATS IPVS_TUN_TYPE IPVS_TUN_CSUM IPVS_TUN_GRE VRRP_IPVLAN IFLA_LINK_NETNSID GLOB_BRACE GLOB_ALTDIRFUNC INET6_ADDR_GEN_MODE VRF SO_MARK

Distro (please complete the following information):
Debian GNU/Linux 13 (trixie)
aarch64

Details of any containerisation or hosted service (e.g. AWS)
Baremetal

Configuration file:

global_defs {
    script_user keepalived_script
    enable_script_security
    max_auto_priority
}

vrrp_script check_pihole {
    script "/etc/keepalived/check_pihole.sh"
    interval 2
    weight -20
}

vrrp_instance VI_1 {
    state MASTER            # BACKUP for secondary
    interface eth0         
    virtual_router_id 51    # Must match on both nodes
    priority 150            # 140 for BACKUP
    advert_int 1
    
    authentication {
        auth_type PASS
        auth_pass ***
    }

    virtual_ipaddress {
        192.168.250.4/24
    }

    track_script {
        check_pihole
    }

    # This single line handles all state transitions
    # It passes: $1=INSTANCE, $2=VI_1, $3=STATE
    # Note that this is a workaround to manually force group membership
    notify "/etc/keepalived/notify.sh" keepalived_script notify-access

[anourai]

Looking at the source code, I can see it is a design choice to clear all supplementary groups.

Here is my use case:

My notify script runs as keepalived_script per default.

The keepalived notify script sources environment variables from an external .env file that contains API keys used for authorisation for invoking a cloud push messaging service.

The env file has “notify-access” group ownership and 640 permissions so that the keys can only be read with that membership in that group.

I have a number of other scripts that source the .env file and I control access to those keys by adding notify-access as a supplementary group to whatever user runs those scripts.

I’d be curious as to the reasoning for clearing supplementary groups and for any advice on how you would otherwise control access to the keys in my .env file.

For now, the workaround in my keepalived.conf is working.

[pqarmitage]

The reason for clearing the supplementary groups is that keepalived is expected to be run as user root, and consequently the supplementary group list of the process will be root's supplementary group list. We clearly, when running a process (e.g. script) as a non-root user, don't want the process to run with root's supplementary group list.

I think that because keepalived current doesn't set the supplementary group list, we shouldn't change the default behaviour to start setting the supplementary group list. However, we could add a new global_defs keyword, e.g. script_set_supplementary_groups which will cause the supplementary groups of the configured script user(s) to be set.

[anourai]

The logic for clearing the groups and proposed feature both make sense to me.