You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hello everyone. I have a podman container which was created by ubuntu:22.04 image. A bug occurred after a certain kernel update. There was a problem with the file permissions in my container. Specifically, when I used podman run --it -v /home/flower/CTFhub:/home/flower/CTFhub:rw --group-add $(getent group flower | cut -d: -f3) --userns keep-id -u $(id -u flower):$(id -g flower) littflower/dockerpwn:v6 bash to create a container and attached it, I got:
I thought when I type sudo it should work fine and give me superuser rights.
podman info output
The following is my system configuration information:
$ podman versionClient: Podman EngineVersion: 5.0.2API Version: 5.0.2Go Version: go1.22.2Git Commit: 3304dd95b8978a8346b96b7d43134990609b3b29-dirtyBuilt: Thu Apr 18 19:13:19 2024OS/Arch: linux/amd64$ podman infohost:
arch: amd64buildahVersion: 1.35.3cgroupControllers:
- memory
- pidscgroupManager: systemdcgroupVersion: v2conmon:
package: /usr/bin/conmon 由 conmon 1:2.1.10-1 所拥有path: /usr/bin/conmonversion: 'conmon version 2.1.10, commit: 2dcd736e46ded79a53339462bc251694b150f870'cpuUtilization:
idlePercent: 95.44systemPercent: 0.75userPercent: 3.81cpus: 20databaseBackend: sqlitedistribution:
distribution: archversion: unknowneventLogger: journaldfreeLocks: 2030hostname: ArchLinuxidMappings:
gidmap:
- container_id: 0host_id: 1000size: 1
- container_id: 1host_id: 100000size: 65536uidmap:
- container_id: 0host_id: 1000size: 1
- container_id: 1host_id: 100000size: 65536kernel: 6.8.7-arch1-1.1-g14linkmode: dynamiclogDriver: journaldmemFree: 5492482048memTotal: 16377323520networkBackend: netavarknetworkBackendInfo:
backend: netavarkdns:
package: Unknownpackage: /usr/lib/podman/netavark 由 netavark 1.10.3-1 所拥有path: /usr/lib/podman/netavarkversion: netavark 1.10.3ociRuntime:
name: crunpackage: /usr/bin/crun 由 crun 1.14.4-2 所拥有path: /usr/bin/crunversion: |- crun version 1.14.4 commit: a220ca661ce078f2c37b38c92e66cf66c012d9c1 rundir: /run/user/1000/crun spec: 1.0.0 +SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +YAJLos: linuxpasta:
executable: /usr/bin/pastapackage: /usr/bin/pasta 由 passt 2024_04_26.d03c4e2-1 所拥有version: | pasta 2024_04_26.d03c4e2 Copyright Red Hat GNU General Public License, version 2 or later <https://www.gnu.org/licenses/old-licenses/gpl-2.0.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law.remoteSocket:
exists: falsepath: /run/user/1000/podman/podman.socksecurity:
apparmorEnabled: falsecapabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOTrootless: trueseccompEnabled: trueseccompProfilePath: /etc/containers/seccomp.jsonselinuxEnabled: falseserviceIsRemote: falseslirp4netns:
executable: /usr/bin/slirp4netnspackage: /usr/bin/slirp4netns 由 slirp4netns 1.3.0-1 所拥有version: |- slirp4netns version 1.3.0 commit: 8a4d4391842f00b9c940bb8f067964427eb0c964 libslirp: 4.7.0 SLIRP_CONFIG_VERSION_MAX: 4 libseccomp: 2.5.5swapFree: 8579969024swapTotal: 8589930496uptime: 4h 60m 48.00s (Approximately 0.17 days)variant: ""plugins:
authorization: nulllog:
- k8s-file
- none
- passthrough
- journaldnetwork:
- bridge
- macvlan
- ipvlanvolume:
- localregistries:
search:
- docker.iostore:
configFile: /home/flower/.config/containers/storage.confcontainerStore:
number: 18paused: 0running: 2stopped: 16graphDriverName: overlaygraphOptions: {}graphRoot: /home/flower/.local/share/containers/storagegraphRootAllocated: 923336273920graphRootUsed: 390578380800graphStatus:
Backing Filesystem: extfsNative Overlay Diff: "true"Supports d_type: "true"Supports shifting: "false"Supports volatile: "true"Using metacopy: "false"imageCopyTmpDir: /var/tmpimageStore:
number: 9runRoot: /run/user/1000/containerstransientStore: falsevolumePath: /home/flower/.local/share/containers/storage/volumesversion:
APIVersion: 5.0.2Built: 1713438799BuiltTime: Thu Apr 18 19:13:19 2024GitCommit: 3304dd95b8978a8346b96b7d43134990609b3b29-dirtyGoVersion: go1.22.2Os: linuxOsArch: linux/amd64Version: 5.0.2
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
Additional information
The cause of this problem may be that I did not restart the system immediately after updating the kernel, which caused unexpected things to happen to the container.
The text was updated successfully, but these errors were encountered:
Did you check the file permissions on the sudo binary? Is the underlying file system mounted nosuid maybe, etc...
Also please do not provide sceenshots of terminal text, always copy and paste it which makes it much more readable.
In any case I don't see how this is podman bug so I move it to a discussion
Issue Description
Hello everyone. I have a podman container which was created by ubuntu:22.04 image. A bug occurred after a certain kernel update. There was a problem with the file permissions in my container. Specifically, when I used
podman run --it -v /home/flower/CTFhub:/home/flower/CTFhub:rw --group-add $(getent group flower | cut -d: -f3) --userns keep-id -u $(id -u flower):$(id -g flower) littflower/dockerpwn:v6 bash
to create a container and attached it, I got:The attach command looks like this:
you can find my image here
thanks for your help.
Steps to reproduce the issue
Steps to reproduce the issue
podman run --it -v /home/flower/CTFhub:/home/flower/CTFhub:rw --group-add $(getent group flower | cut -d: -f3) --userns keep-id -u $(id -u flower):$(id -g flower) littflower/dockerpwn:v6 bash
su -
Describe the results you received
just like these:
Describe the results you expected
I thought when I type
sudo
it should work fine and give me superuser rights.podman info output
Podman in a container
No
Privileged Or Rootless
None
Upstream Latest Release
Yes
Additional environment details
Additional information
The cause of this problem may be that I did not restart the system immediately after updating the kernel, which caused unexpected things to happen to the container.
The text was updated successfully, but these errors were encountered: