Socket truncated with long user names using default $XDG_RUNTIME_DIR

[fool65c]

Is this a BUG REPORT or FEATURE REQUEST?

/kind bug

Socket truncated with long user names using default $XDG_RUNTIME_DIR

Steps to reproduce the issue:

1. have a long username such as 11111111

2. run podman run -it ubuntu

Describe the results you received:
podman fails to attach to the running container

DEBU[0003] Received: 20102
INFO[0003] Got Conmon PID as 20092
DEBU[0003] Created container 7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e in OCI runtime
DEBU[0003] Attaching to container 7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e
DEBU[0003] connecting to socket /var/run/user/11111111/libpod/tmp/socket/7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e/a
DEBU[0003] ExitCode msg: "failed to connect to container's attach socket: /var/run/user/11111111/libpod/tmp/socket/7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e/a: dial unixpacket /var/run/user/11111111/libpod/tmp/socket/7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e/a: connect: no such file or directory"
Error: failed to connect to container's attach socket: /var/run/user/11111111/libpod/tmp/socket/7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e/a: dial unixpacket /var/run/user/11111111/libpod/tmp/socket/7e19533164c776b5965dfb17891efd6d2eda50059190d00e5e2765c60323d38e/a: connect: no such file or directory

Describe the results you expected:
user able to attach to the container

Additional information you deem important (e.g. issue happens only occasionally):

This appears to be because of a system limit addr.sun_path because the socket is truncated:
https://github.com/containers/podman/blob/master/libpod/oci_attach_linux.go#L187

Based on addr.sun_path here:

podman/libpod/oci_attach_linux_cgo.go

Line 6 in b68b6f3

// extern int unix_path_length(){struct sockaddr_un addr; return sizeof(addr.sun_path) - 1;}

Is this a system setting we can change?

Also, will a truncated socket ever work after it was created? The File not found error is true, however a bit misleading because the real issue is the socket that was created exceeded system limits.

Output of podman version:

podman -v
podman version 2.2.1

Output of podman info --debug:

(paste your output here)

Package info (e.g. output of rpm -q podman or apt list podman):

apt list podman
Listing... Done
podman/unknown,now 2.2.1~4 amd64 [installed]

Have you tested with the latest version of Podman and have you checked the Podman Troubleshooting Guide?

Yes

Additional environment details (AWS, VirtualBox, physical, etc.):
Setting the XDG_RUNTIME_DIR to a shorter string solves the issue

echo $XDG_RUNTIME_DIR
/var/qt/user

DEBU[0000] Received: 19653
INFO[0000] Got Conmon PID as 19642
DEBU[0000] Created container 7ccae949dc82d7a88b6f1acdfdf9e7c9abbcc472583ee57e990da816c19252f6 in OCI runtime
DEBU[0000] Attaching to container 7ccae949dc82d7a88b6f1acdfdf9e7c9abbcc472583ee57e990da816c19252f6
DEBU[0000] connecting to socket /var/qt/user/libpod/tmp/socket/7ccae949dc82d7a88b6f1acdfdf9e7c9abbcc472583ee57e990da816c19252f6/attach
DEBU[0000] Starting container 7ccae949dc82d7a88b6f1acdfdf9e7c9abbcc472583ee57e990da816c19252f6 with command [bash]
DEBU[0000] Received a resize event: {Width:217 Height:45}
DEBU[0000] Started container 7ccae949dc82d7a88b6f1acdfdf9e7c9abbcc472583ee57e990da816c19252f6
DEBU[0000] Enabling signal proxying
root@7ccae949dc82:/#

[rhatdan]

@giuseppe @mheon I thought we dealt with something like this before?

[mheon]

Can't locate the PR, but I know we have hit this before. I believe the fix was to truncate container ID to ensure maximum length restriction was satisfied?

[faulesocke]

Having the same problem. This also happens with short usernames (5 chars) and my XDG_RUNTIME_DIR=/tmp/runtime-$USER. In my case the last character got stripped.

[faulesocke]

I can also confirm that the socket was successfully created. So having longer paths isn't a problem. Instead of doing any kind of truncation logic I would suggest to simply chdir into the correct directory. Then the path becomes a fixed string ("attach").

[rhatdan]

Interested in opening a PR to do this?

[faulesocke]

Sorry, my go knowledge is practically nonexistent and it would certainly take multiple iterations for me to get this right and nice while someone else with knowledge of go and probably the codebase can do it in 2 minutes. Would it have been in some other language like C or Rust - I would have opened a PR in the first place without even commenting here.

[rhatdan]

No problem, hopefully someone from the community will pick this up. Most of Red Hat is supposed to be on PTO this week.

[stephankoelle]

Same issue here, uid is very long, socket name is over 108 chars, podman does not start.

[stephankoelle]

Changing XDG_RUNTIME_DIR does not help in our case, the data is there, but the path to the socket is not altered.

[mheon]

@haircommander Is this related to the Conmon change we were discussing yesterday?

[haircommander]

yes most likely!

[fool65c]

I'm interested in taking a stab at this, is the preferred approach still changing the directory?

[rhatdan]

I believe so.
@haircommander WDYT?

[rhatdan]

@mheon is this something we need to fix before 3.0?

[mheon]

I think we definitely need a fix, yeah - either an updated Conmon that does not enable this by default, a Podman patched to work with newer Conmon, or both.

…

On Sun, Jan 10, 2021 at 06:58 Daniel J Walsh ***@***.***> wrote: @mheon <https://github.com/mheon> is this something we need to fix before 3.0? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#8798 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AB3AOCD4LG3TIASIM6GIAOTSZGI5JANCNFSM4VEKXKHA> .

[stephankoelle]

Is there an attack point for a work around? (beside running podman as root - short uid user)

[giuseppe]

could you please try if #8933 solves the issue you are seeing?

[stephankoelle]

The fix in podman 3 works, the bug is gone with a freshly built podman and very long uid.

[thoniTUB]

Is this going to be fix for podman 2 since it comes with RHEL 8.3?

[mheon]

We discussed an async release for this, but it appeared too late in the release cycle to be worth it. RHEL 8.4 should be releasing soon with a fixed Podman.