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); Cheers, Michael -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Linux/UNIX System Programming Training: http://man7.org/training/ -- 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
