archive mirror
 help / color / mirror / Atom feed
From: (Eric W. Biederman)
To: "Michael Kerrisk \(man-pages\)" <>
Cc: "Serge E. Hallyn" <>,,,, Andrey Vagin <>,
	James Bottomley <>,
	"W. Trevor King" <>,
	Alexander Viro <>,
	Jonathan Corbet <>
Subject: Re: [PATCH 0/2] Add further ioctl() operations for namespace discovery
Date: Thu, 22 Dec 2016 13:27:41 +1300	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <> (Michael Kerrisk's message of "Wed, 21 Dec 2016 10:53:00 +0100")

"Michael Kerrisk (man-pages)" <> writes:

> Hi Eric,
> On 12/21/2016 01:17 AM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" <> writes:
>>> Hi Eric,
>>> On 12/20/2016 09:22 PM, Eric W. Biederman wrote:
>>>> "Michael Kerrisk (man-pages)" <> writes:
>>>>> Hello Eric,
>>>>> On 12/19/2016 11:53 PM, Eric W. Biederman wrote:
>>>>>> "Michael Kerrisk (man-pages)" <> 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
> 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.


  reply	other threads:[~2016-12-22  1:16 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-12-19 14:38 [PATCH 0/2] Add further ioctl() operations for namespace discovery Michael Kerrisk (man-pages)
2016-12-19 22:53 ` Eric W. Biederman
2016-12-20 15:35   ` Michael Kerrisk (man-pages)
2016-12-20 20:22     ` Eric W. Biederman
2016-12-20 20:55       ` Michael Kerrisk (man-pages)
2016-12-21  0:17         ` Eric W. Biederman
2016-12-21  9:53           ` Michael Kerrisk (man-pages)
2016-12-22  0:27             ` Eric W. Biederman [this message]
2016-12-22  7:20               ` Michael Kerrisk (man-pages)
2016-12-22 10:28                 ` Eric W. Biederman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).