Replies: 2 comments
-
The original set of capabilities was defined by Docker, which did not include dac_read_search. Podman followed the default, but removed some questionable ones. mknod, net_raw, cap_audit_write. I would prefer to remove capabilities from the default list, but this would break existing users. For example I see little reason for cap_setpcap and cap_setfcap (Except in the case of building), Not sure of cap_fsetid or cap_fowner either. dac_override has all of the powers of dac_read_search, I believe, so making both defaults, seems of limited value. If you want to remove dac_override, you probably know enough to add dac_read_search. |
Beta Was this translation helpful? Give feedback.
-
Thank you. |
Beta Was this translation helpful? Give feedback.
-
I've recently hit an issue https://bugzilla.redhat.com/show_bug.cgi?id=2334087 when removing cap_dac_override and keeping cap_dac_read_search works on host (for a sssd:sssd process to read /etc/krb5.keytab with root:root and -rw-------) but not in containers.
Checking
I see that the container has
cap_dac_override
but notcap_dac_read_search
. Reading capabilities(7) it looks likecap_dac_read_search
might be a less "powerful" capability thancap_dac_override
. (This is with podman-5.3.1-1.fc41.x86_64. Output withsudo podman
is the same.)Is there a specific reason why podman containers by default enables
cap_dac_override
but does not addcap_dac_read_search
?Beta Was this translation helpful? Give feedback.
All reactions