Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

The fixed user seems to lose other groups #30

Closed
felipecrs opened this issue Sep 3, 2020 · 6 comments · Fixed by #37
Closed

The fixed user seems to lose other groups #30

felipecrs opened this issue Sep 3, 2020 · 6 comments · Fixed by #37

Comments

@felipecrs
Copy link

If the user is part of more groups than the dockergroup (the group which fixuid changes), those groups do not get applied in the new user.

@felipecrs felipecrs changed the title Group changes does not seem to take effect The user seems to lose other groups Sep 3, 2020
@felipecrs felipecrs changed the title The user seems to lose other groups The fixed user seems to lose other groups Sep 3, 2020
@caleblloyd
Copy link
Collaborator

caleblloyd commented Jul 19, 2021

Secondary groups are specified in /etc/groups in the 4th column, which is referenced by username

In the case the container is run with the UID of an existing user that does not match the name of the configured fixuid user, the UID is not changed, so secondary groups will not match:

fixuid/fixuid.go

Lines 138 to 147 in 4467c25

} else {
oldUID = ""
newUID = ""
if existingUser == containerUser {
logInfo("runtime UID '" + runtimeUID + "' already matches container user '" + containerUser + "' UID")
} else {
logInfo("runtime UID '" + runtimeUID + "' matches existing user '" + existingUser + "'; not changing UID")
needChown = true
}
}

But in the typical case that the container is run with a UID that does not match any user in /etc/passwd, the UID of the configured fixuid user will be changed, but the secondary groups from /etc/group will still match, since they are referenced by username

@felipecrs
Copy link
Author

@caleblloyd so sorry, but I didn't understand much of your reply.

I'm back to say that, if a group is required to be present you can ensure its presence with docker run --group-add <group-name>, in my case docker run --group-add=docker.

@molohov
Copy link

molohov commented Apr 20, 2023

This issue is still present.
Even if user is part of secondary groups in /etc/group, the user's groups only reflect what is set in /etc/fixuid/config.yml. You can verify this by running groups
Running with @felipecrs workaround will make the group present in the output of groups

@aigarius
Copy link

The problem lies in the ExitOrExec function that is executing the next process after doing all the changes. It is setting the euid and egid, but not looking up and setting additional groups from /etc/group from inside the container.

@caleblloyd
Copy link
Collaborator

@aigarius good catch - it was not recomputing /etc/passwd and /etc/group - opened #37 to address

felipecrs added a commit to felipecrs/fixdockergid that referenced this issue Aug 26, 2023
As the new fixuid version correctly retains the groups for the user.

Refs boxboat/fixuid#30
felipecrs added a commit to felipecrs/fixdockergid that referenced this issue Aug 26, 2023
As the new fixuid version correctly retains the groups for the user.

Refs boxboat/fixuid#30
Refs boxboat/fixuid#37
@felipecrs
Copy link
Author

With this fix I was able to greatly simplify fixdockergid and drop the dependency on setpriv for it. Thanks a lot!

felipecrs/fixdockergid@ce80584

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants