Why are uid / gid set to 1001 / 999?

[tc-tmmlt]

Environment:

• LXC unprivileged container on Proxmox
• Oodles of resources; stock and fresh ubuntu Jammy / docker

Issue:

• Docker compose fails with:
  failed to register layer: ApplyLayer exit status 1 stdout: stderr: unlinkat /var/cache/apt/archives: invalid argument
• regular redis has no such issue on same container = what is different?

Diagnosis:

• Unprivileged containers on LXC are sensitive to gid / uid > local settings = yes, small set of users
• Worst case is when uid / gid > 65536, but in this case uid > anything local = throwing an error
• Looked at the uid & gid of the redis stack items -- see below (pretty colors = exa; enjoy the rainbow)

I'm going to try building my own to see if a local build resolves the issue

However, could I ask someone to (pretty please) chown those files to root before they get tarred on the next release?

Thanks!

[chayim]

@tc-tmmlt I'm not against chowning them to root (at all!) just curious as to why you want them chowned to root. They take the default IDs assigned by the builder, today. Mostly, this is history due to how other redis packages were built.

I agree that files in /usr/bin (example) are clearly root:root. But the uid/gid being in a "user" block (i.e linux default first user 1000) is problematic. I guess the only real issue is writing the rdb out to filesystem, for those using persistence - this will now break those users, in some cases.

WDYT?

[tc-tmmlt]

@chayim -- thanks for the response. I wish I still had that container in dev so I could refer back to it, but IIRC:

• I prefer to assemble stock rather than build images. You're seeing vestiges from build above because I had to resort to it. I could chown things differently in a build sequence, for sure, but..
• When you assemble, if you are doing so in an LXC container, collisions in userspace (uids) are very rare, but are a nightmare that sometimes involves turning off docker overlayfs to solve (insane as that may sound).
• Stock redis (in docker) has never given me such a collision / issue, so I verified that they have chowned all of those files to root, which begged the question of why redis stack was doing things differently (honest ignorance: why the diff?)
• If mainline redis has no issues writing rdb to disk given their files are chowned to root, I'm not sure why stack would have an issue writing out to the FS, but I caveat that with the same honest ignorance -- you know far, far better than I

I found an OK work-around by downloading the commercial rejson.so and loading it via config. I'd love to load the whole of redis stack, but that was the part I could not live without. (leaving that in here as breadcrumb for others). Best, TC