"Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes: > Hi Eric, > > On 12/22/2016 01:27 AM, Eric W. Biederman wrote: >> "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. > > Okay. > >>>> 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. > > Okay. > >> 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. > > > See my reply just sent to Andrei. We should instead then just return > the UID via a buffer pointed to by the ioctl() argument: > > ioctl(fd, NS_GET_OWNER_UID, &uid); That will work without problem. Especially as unsigned int is the same on both 32bit and 64bit so we won't need a compat ioctl. Eric -- 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
