"Michael Kerrisk (man-pages)" [off-list ref] writes:

Hi Eric,

On 12/22/2016 01:27 AM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hi Eric,

On 12/21/2016 01:17 AM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hi Eric,

On 12/20/2016 09:22 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

Hello Eric,

On 12/19/2016 11:53 PM, Eric W. Biederman wrote:

quoted

"Michael Kerrisk (man-pages)" [off-list ref] writes:

quoted

quoted

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.

quoted

quoted

quoted

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.

quoted

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