On Thu, Feb 26, 2015 at 11:32 AM, Serge E. Hallyn <serge@xxxxxxxxxx> wrote: > On Thu, Feb 26, 2015 at 12:28:30PM -0600, Christoph Lameter wrote: >> On Thu, 26 Feb 2015, Serge E. Hallyn wrote: >> >> > > Well doing that breaks su. >> > >> > Don't what exactly? You're saying that doing >> > >> > pI' = pI >> > pA' = pA (pA is ambient) >> > pP' = (X & fP) | (pI & (fI | pA)) >> > pE' = pP' & (fE | pA) >> > >> > stopped su from having CAP_SETGID while >> > >> > pI' = pI >> > pA' = pA (pA is ambient) >> > pP' = (X & fP) | (pI & (fI | pA)) >> > pE' = pP' & fE >> > >> > worked? I'll hope you're saying both "fail", in which case >> >> fE does not exist in cpu_vfs_cap_data. We only get fI and fP. Why in the >> world does setcap allow setting fE? > > It sets a bit in the magic_etc. So fE is either all on or all off. > >> V1 does not use fE. In my newer attempt, I seemed to have worked >> with zeroed field that I assumed was filled in. >> >> I will just do >> >> pE' = pP' >> >> Ok? > > Andrew Morgan was against that. What if we changed > > pE' = pP' & (fE | pA) > > to > > if (pA) > pE' = pP' & fE > else > pE' = pP' > Is this backwards? Also, on further bikeshedding consideration, I think I like the name "persistent" much better than "ambient". Alas, "persistent" starts with a P. --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-api" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html