(Seemingly?) undocumented default capabilities change in 4.4.0+

[nitzmahone]

Issue Description

The change to default capabilities over in containers/common that was picked up in 4.4.0 is a pretty major breaking change that's probably worth at least adding to podman's changelog- we got nailed by this one when all our containers that were running sshd started failing on sshd's internal chroot after upgrading from 4.3.1 to 4.4.1 under Fedora 37 and had to chase down what had changed by digging around in commits to podman's deps.

Steps to reproduce the issue

Steps to reproduce the issue

1. Run any operation in an unprivileged rootless container that requires one of the new removed default capabilities

Describe the results you received

Anything using previously default privileges now fails, checking changelogs and podman commits doesn't help figure out why it just stopped working.

Describe the results you expected

User-visible breaking changes in podman's vendored libs should probably be surfaced in podman changelogs

podman info output

N/A

Podman in a container

No

Privileged Or Rootless

Rootless

Upstream Latest Release

Yes

Additional environment details

N/A

Additional information

N/A

[Luap99]

I agree that should have been made clear in the realse notes, not sure why it wasn't.
cc @rhatdan
Here is a bit more explanation why it was changed: https://blog.podman.io/2022/12/dropping-capabilities-making-containers-more-secure/

AFAIK we usually do not edit release notes after the fact so I am not sure if there is much we can do. @mheon @ashley-cui WDYT?

[ashley-cui]

Ah, since it was a change in c/common I don't think I picked up the change for the release notes, since it probably just slipped in via a c/common vendor. I'll let @mheon make the call on the release notes, maybe we can add a note to the github release page, but not edit the actual release_notes.md?

[mheon]

We've edited release notes before, but mostly to add CVE numbers. Breaking changes seem appropriate as well, so I have no objection to adding this.

[nitzmahone]

TBC, I have no issue with the actual behavior change- yay for fewer default privileges! Just mostly trying to ensure there's an easier way than trolling commits to figure out what happened, both now and in the future.

Thanks for all you do- podman rules!

[nitzmahone]

Also: I'm not sure the statement that Fedora and others have already been running with these defaults is accurate- I'm on vanilla Fedora 37 with no ~/.config/containers/containers.conf and an (apparently) bone-stock /usr/share/containers/containers.conf that was recently updated by the system a couple weeks ago (a matching config to a bunch of our CI workers). The cap set mentioned in that blog post doesn't appear in that config (everything is commented out, which I believe is the system default), and things that needed CAP_CHROOT didn't break until we went from 4.3.1 to 4.4.1. Again not taking issue with the change, but unless we're doing something weird we don't know about, there may be a lot more folks that will trip over this than originally thought.

[nitzmahone]

I do see that explicit config was recently removed in F37, just not sure why it didn't seem to be having any effect...

https://src.fedoraproject.org/rpms/containers-common/c/457b548243dd5d4315f0e76e15daa753ac6cade9?branch=f37

Ah well, anyway, hope we're a weird anomaly on this one. Thanks again for everything!

[github-actions]

A friendly reminder that this issue had no activity for 30 days.

[ashley-cui]

Updated release notes, closing..

[Luap99]

I still think we should revert that change. We got several issues about this. This is clearly breaking many people and breaking changes should not be acceptable in minor versions unless absolutely necessary.

[rhatdan]

We can change the default in Fedora for the distro, since this is more secure, I don't think we should change the default in containers/common.