Quoting Chris Friedhoff ([EMAIL PROTECTED]): > Hello, > > in updating the documetation http://www.friedhoff.org/posixfilecaps.html > I noticed a change in the behavior. > > There was the behavior, when the extended attribute capability was > present but with empty sets, even a suid-0-bit binary was not having > the right to request a call for which capabilities in-kernel are > defined. suid-0-bit ping with an empty capability set provoked an EPERM > > Now, when the extended attribute is present but empty and for ping - as > an example - cap_net_raw is not granted, root-power overrules the lack > of the necessary capability. > > Shall the presents of file capability constrain root power or shall > root power overrule file capability?
I think the only rule we can reasonably use is: existing setuid semantics shall not be adversely affected by capabilities. So when !issecure(SECURE_NOROOT), then a setuid root binary should always run with all root privileges (barring capability bounding sets). However if issecure(SECURE_NOROOT), then a setuid root binary should run with no special privileges. But I don't expect anyone to really use that until Andrew Morgan resubmits the per-process SECURE_NOROOT patch. My question is - when did it ever behave differently?? -serge - To unsubscribe from this list: send the line "unsubscribe linux-security-module" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
