user: Always return supplementary groups

[mrunalp]

The caller can ignore it if they don't care about using them.

cc: @cyphar @runcom

Signed-off-by: Mrunal Patel [email protected]

[mrunalp]

This allows one to get all the data in just one call rather than having to call into the function and parse the files twice.

[tianon]

The caller can ignore it if they don't care about using them.

How would the caller detect the case that the current code handles? By the time it gets back to the caller, isn't that information lost?

The current implementation is such that 1000:1000 doesn't give me any supplementary groups, but 1000, tianon, etc do (which IMO is a pretty explicit difference -- in one, I'm asking for a specific group, in the other I'm assuming there's some default group and thus supplementary groups are desirable).

[mrunalp]

@tianon We can make this a parameter to the function if required to distinguish between the two cases. wdyt?

[runcom]

@cyphar could you have a look at this please?

[cyphar]

Last time we touched this code (#1450) quite a few issues were caused. What is the primary justification for changing this? Semantically if someone asks to run as 1000:1000 I would find it very strange that they have more supplementary groups -- especially since there are already other library functions to get this information (as well as a separate flag in runc now).