"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > Hi Eric, > > On 12/21/2016 01:17 AM, Eric W. Biederman wrote: >> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >> >>> Hi Eric, >>> >>> On 12/20/2016 09:22 PM, Eric W. Biederman wrote: >>>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>>> >>>>> Hello Eric, >>>>> >>>>> On 12/19/2016 11:53 PM, Eric W. Biederman wrote: >>>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: >>>>>> >> Now the question becomes who are the users of this? Because it just >> occurred to me that we now have an interesting complication. Userspace >> extending the meaning of the capability bits, and using to protect >> additional things. Ugh. That could be a maintenance problem of another >> flavor. Definitely not my favorite. > > I don't follow you here. Could you say some more about what you mean? I have seen user space userspace do thing such as extend CAP_SYS_REBOOT to things such as permission to invoke "shutdown -r now". Which depending on what a clean reboot entails could be greately increasing the scope of CAP_SYS_REBOOT. I am concerned for that and similar situations that userspace applications could lead us into situation that one wrong decision could wind up being an unfixable mistake because fixing the mistake would break userspsace. >> So why are we asking the questions about what permissions a process has? > > My main interest here is monitoring/discovery/debugging on a running > system. NS_GET_PARENT, NS_GET_USERNS, NS_GET_CREATOR_UID, and > NS_GET_NSTYPE provide most of what I'd like to see. Being able to ask > "does this process have permissions in that namespace?" would be nice > to have in terms of understanding/debugging a system. If we are just looking at explanations then I seem to have been over-engineering things. So let's just aim at the two ioctls. Or at least the information in those ioctls. With at least a comment on the ioctl returning the OWNER_UID that describes why it is not a problem to if the owners uid is something like ((uid_t)-3). Which overlaps with the space for error return codes. I don't know if we are fine or not, but that review comment definitely deserves some consideration. Eric -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
