The USER command does not set the correct gids, so extra groups are dropped

[dren-dk]

Actual behavior

When adding a user with an additional group and setting the user with USER, the user isn't a member of the group, according to id

Expected behavior

Users should be a member of all the groups listed in /etc/group

To Reproduce

mkdir user-group
cat user-group/Dockerfile

FROM ubuntu:latest

RUN groupadd -g 20000 bar
RUN groupadd -g 10000 foo

RUN useradd -c "Foo user" -u 10000 -g 10000 -G bar -m foo

RUN id foo

USER foo

RUN id

docker run --rm -it -v pwd/user-group:/workspace gcr.io/kaniko-project/executor:v0.17.1 --no-push

Observe:

INFO[0007] RUN id foo                                   
INFO[0007] cmd: /bin/sh                                 
INFO[0007] args: [-c id foo]                            
uid=10000(foo) gid=10000(foo) groups=10000(foo),20000(bar)
INFO[0007] Taking snapshot of full filesystem...        
INFO[0007] No files were changed, appending empty layer to config. No layer added to image. 
INFO[0007] USER foo                                     
INFO[0007] cmd: USER                                    
INFO[0007] RUN id                                       
INFO[0007] cmd: /bin/sh                                 
INFO[0007] args: [-c id]                                
uid=10000(foo) gid=10000(foo) groups=10000(foo)

As you can see the second id command shows that the foo user is not a member of bar, even though the first id command had the right answer.

Triage Notes for the Maintainers

Description	Yes/No
Please check if this a new feature you are proposing
Please check if the build works in docker but not in kaniko	- [V]
Please check if this error is seen when you use --cache flag
Please check if your dockerfile is a multistage dockerfile

[dren-dk]

Note: I have just reproduced the problem with master (b538066)

[tejal29]

This should be fixed by #1072 i will verify on the branch

[tejal29]

This is still an issue and i will address this in next release.

[tstromberg]

The TL;DR for this issue is that Kaniko neglected to set the secondary groups field in the syscall.Credential struct that was passed to exec.Cmd object. The complication is that kaniko builds without cgo, so looking up secondary groups is not possible with the built-in user.User.GroupIds() function.

Thankfully, kaniko is only designed to function in a known Docker container running Linux, so it's trivial to implement a working !cgo version, albeit with a tiny performance penalty.

Sent in an initial PR for review, though I expect it will take some days to land as this is my first Kaniko PR.