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

Check if uid is not higher than maxuid and gid is not higher than maxgid, otherwise exit with message. #4838

Closed
mangonel opened this issue Sep 21, 2019 · 10 comments · Fixed by #4839
Assignees
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.

Comments

@mangonel
Copy link

Error is non descriptive

id
uid=70000(test) gid=1001(test) groups=1001(test)
toolbox enter
Error: unable to start container "fedora-toolbox-30": container_linux.go:346: starting container process caused "process_linux.go:319: getting the final child's pid from pipe caused \"EOF\"": OCI runtime error

My guess this is caused by:
--userns=keep-id
Which requires uid not to be greater than maxUID and gid not to be greater than maxGID.
With maxUID being the third field in subuid and maxGID being the third field in subgid.

@mangonel
Copy link
Author

userns=keep-id
f09370c

@mangonel
Copy link
Author

Fails when uid = maxUID.
So uid must be less than maxUID and gid must be less than maxGID.

@debarshiray
Copy link
Member

This sounds a bit like #4047

I see that your UID is 70000. What does your /etc/subuid look like?

@mangonel
Copy link
Author

mangonel commented Sep 25, 2019

My subordinate user ID count is 65536 (the default.)
As an experienced user I know I how to change this default.
The useradd command automatically set the max subordinate user and group ID's in /etc/subuid and /etc/subgid. Without me knowing.
So a beginner needs a message to assist to assist them in increasing these default values.

When a user with a uid or gid >= max subordinate user or group id (65536 by default) try to run toolbox, they receive an error which is very difficult to fault find.
Please message the the user, telling them to increase their subordinate user or group ID count in either /etc/subuid or /etc/subgid so that toolbox can run.

@debarshiray
Copy link
Member

Could you please give an example /etc/subuid entry and a corresponding host UID that reproduces this bug? I think I understand what you are saying but having a clear example will be very helpful so that I am sure that we are looking at the same problem.

@mangonel
Copy link
Author

Currently not at my fedora box. WIll provide examples and the output of the following.

    uid=$(id -u)
    gid=$(id -g)
    subuid_entry=$(grep "^$USER:" /etc/subuid)
    subgid_entry=$(grep "^$USER:" /etc/subgid)
    userns_uid_start=$(echo "$subuid_entry" | cut --delimiter ":" --fields 2)
    userns_uid_len=$(echo "$subuid_entry" | cut --delimiter ":" --fields 3)
    userns_gid_start=$(echo "$subgid_entry" | cut --delimiter ":" --fields 2)
    userns_gid_len=$(echo "$subgid_entry" | cut --delimiter ":" --fields 3)

    if [ "$uid" -ge "$userns_uid_len" ]; then
      echo "usermod --add-subuids $userns_uid_start-$(($userns_uid_start + $uid)) $USER"
    fi

    if [ "$gid" -ge "$userns_gid_len" ]; then
      echo "usermod --add-subgids $userns_gid_start-$(($userns_gid_start + $gid)) $USER"
    fi

@mangonel
Copy link
Author

mangonel commented Oct 31, 2019

Easy to make a mistake with enterprise logins.
An account could be created like follows:

sudo groupadd --gid 70000 test
sudo useradd --uid 70000 --gid 70000 test
id test
uid=70000(test) gid=70000(testing) groups=70000(testing)
sudo usermod --add-subuids 165536-231071 --add-subgids 165536-231071 test
cat /etc/subuid | grep test
test:165536:65536
cat /etc/subgid | grep test
test:165536:65536

This leaves the user with the difficult job of resolving:

toolbox -v enter
toolbox: running as real user ID 70000
Error: unable to start container "fedora-toolbox-31": writing file '/proc/23086/uid_map': Invalid argument
setgid(0): Invalid argument: OCI runtime error
toolbox: failed to start container fedora-toolbox-31

Run my prevous script as the user you will get:

sudo usermod --add-subuids 165536-235536 test
sudo usermod --add-subgids 165536-235536 test

Using this infomation we can fix the problem:

sudo usermod --del-subuids 165536-231071 --del-subgids 165536-231071 test
sudo usermod --add-subuids 165536-235536 --add-subgids 165536-235536 test
cat /etc/subuid | grep test
test:165536:70001
cat /etc/subgid | grep test
test:165536:70001

Toolbox now has enough uid's and gid's in the container to run as the user.

Helpful to message the user with a description of the problem.
Also good to let user know what needs to be run post changing of subuids and subgids.

@A6GibKm
Copy link

A6GibKm commented Nov 15, 2019

In the meantime toolbox could tell the user if his or her subuid/uid is not in the proper range, one user spent months trying to figure out why toolbox was not working with an obscure error message.

@wstering
Copy link

wstering commented Jan 9, 2020

I had the same problem on plain Fedora 31 (not Silverblue) and a simple "podman pull centos:8" using an enterprise login with a high uid (ADS w/ sssd, uid and gid both > 22201000).
mangonel's comment https://github.com/containers/toolbox/issues/268#issuecomment-547697243 helped me get my subuid and subgid files setup correctly. Thanks!

@giuseppe giuseppe transferred this issue from containers/toolbox Jan 10, 2020
@giuseppe giuseppe self-assigned this Jan 10, 2020
@debarshiray
Copy link
Member

Let's fix this in Podman itself.

giuseppe added a commit to giuseppe/libpod that referenced this issue Jan 10, 2020
when creating a keep-id namespace, we split the original user
namespace in:

first ns | second ns | size:
1        | 0         | ID - 1
0        | ID        | 1
0        | ID        | availableIds - ID

When the user ID is bigger than the number of available
subuids/subgids we fail to create the user namespace because the first
slice is bigger than the available number of IDs and the third one has
a negative size.

Fix it by not using more than the available number of IDs in the first
slice and creating the third one only if there are other IDs left.

When the user ID is bigger than the number of additional IDs, there
will be a gap between the two mappings so the IDs between the maximum
additional ID and the user ID won't be present inside of the
namespace.

Closes: containers#4838

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
giuseppe added a commit to giuseppe/libpod that referenced this issue Jan 10, 2020
when creating a keep-id namespace, we split the original user
namespace in:

inner ns | outer ns  | size:
0        | 1         | ID
ID       | 0         | 1
ID+1     | ID+1      | availableIds - ID

When the user ID is bigger than the number of available
subuids/subgids we fail to create the user namespace because the first
slice is bigger than the available number of IDs and the third one has
a negative size.

Fix it by not using more than the available number of IDs in the first
slice and creating the third one only if there are other IDs left.

When the user ID is bigger than the number of additional IDs, there
will be a gap between the two mappings so the IDs between the maximum
additional ID and the user ID won't be present inside of the
namespace.

Closes: containers#4838

Signed-off-by: Giuseppe Scrivano <gscrivan@redhat.com>
@github-actions github-actions bot added the locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments. label Sep 23, 2023
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 23, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked - please file new issue/PR Assist humans wanting to comment on an old issue or PR with locked comments.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants