>> This raises some questions to me. First, does dac_override honor the >> folder permission rules within the profile? For example, if there is a >> rule "/foo/** r," does dac_override this rule? >> (...) > So gpg was run as root and tried to read, write, or execute, a file > (or write to a directory) that it did not have access to via the usual > Unix permissions. It was able to operate on the file because it was run > as root and had CAP_DAC_OVERRIDE in its effective permissions.
Thanks for explanation. Things look clearer now. But, one thing I still don´t get. Isn´t there a collision between dac_override and permission rules in AA profiles? Assume I have such a read only rule in the profile: audit capability dac_override, /tmp/foo r, does dac_override now grant write access to /tmp/foo or does the rule /tmp/foo r, have more priority than dac_override? To me this looks like a permission collision I am not sure how it get handled.... Thanks! -- AppArmor mailing list AppArmor@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/apparmor
