Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754183AbbLOPyR (ORCPT ); Tue, 15 Dec 2015 10:54:17 -0500 Received: from mx2.parallels.com ([199.115.105.18]:43988 "EHLO mx2.parallels.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753274AbbLOPyP (ORCPT ); Tue, 15 Dec 2015 10:54:15 -0500 Date: Tue, 15 Dec 2015 18:53:59 +0300 From: Andrew Vagin To: Andy Lutomirski CC: Roger Luethi , Cyrill Gorcunov , Pavel Emelyanov , Andrey Vagin , Pavel Odintsov , Andrew Morton , Oleg Nesterov , Arnd Bergmann , Linux API , "linux-kernel@vger.kernel.org" , David Ahern , Arnaldo Carvalho de Melo Subject: Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2) Message-ID: <20151215155358.GC24236@odin.com> References: <1436172445-6979-1-git-send-email-avagin@openvz.org> <20151124151811.GA16393@odin.com> <20151214075217.GB4112@odin.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-ClientProxiedBy: US-EXCH2.sw.swsoft.com (10.255.249.46) To US-EXCH.sw.swsoft.com (10.255.249.47) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 4824 Lines: 102 On Mon, Dec 14, 2015 at 02:38:06PM -0800, Andy Lutomirski wrote: > On Dec 13, 2015 11:52 PM, "Andrew Vagin" wrote: > > > > On Thu, Dec 03, 2015 at 03:20:30PM -0800, Andy Lutomirski wrote: > > > On Tue, Nov 24, 2015 at 7:18 AM, Andrew Vagin wrote: > > > > Hello Everybody, > > > > > > > > Sorry for the long delay. I wanted to resurrect this thread. > > > > > > > > Andy suggested to create a new syscall instead of using netlink > > > > interface. > > > >> Would it make more sense to have a new syscall instead? You could > > > >> even still use nlattr formatting for the syscall results. > > > > > > > > I tried to implement it to understand how it looks like. Here is my > > > > version: > > > > https://github.com/avagin/linux-task-diag/blob/task_diag_syscall/kernel/task_diag.c#L665 > > > > I could not invent a better interfaces for it than using netlink > > > > messages as arguments. I know it looks weird. > > > > > > > > I could not say that I understood why a new system call is better > > > > than using a netlink socket, so I tried to solve the problem which > > > > were mentioned for the netlink interface. > > > > > > > > The magor question was how to support pid and user namespaces in task_diag. > > > > I think I found a good and logical solution. > > > > > > > > As for pidns, we can use scm credentials, which is connected to each > > > > socket message. They contain requestor’s pid and we can get a pid > > > > namespace from it. In this case, we get a good feature to specify a pid > > > > namespace without entering into it. For that, an user need to specify > > > > any process from this pidns in an scm message. > > > > > > That seems a little messy. A process can't currently move into > > > another pidns, but how do you make sure you have any pid at all that > > > belongs to the reference pidns? You can, of course, always use your > > > own pid, but that still seems odd to me. > > > > There is your pid by default, you need to do nothing for that. > > If we look at containers or sandboxes, we ussualy know PID of > > the init process. > > > > > > > > > > > > > > > As for credentials, we can get them from file->f_cred. In this case we > > > > are able to create a socket and decrease permissions of the current > > > > process, but the socket will work as before. It’s the common behaviour for > > > > file descriptors. > > > > > > Slightly off-topic, but this netlink is really rather bad as an > > > example of how fds can be used as capabilities (in the real capability > > > sense, not the Linux capabilities sense). You call socket and get a > > > socket. That socket captures f_cred. Then you drop privs, and you > > > assume that the socket you're holding on to retains the right to do > > > certain things. > > > > > > This breaks pretty badly when, through things such as this patch set, > > > existing code that creates netlink sockets suddenly starts capturing > > > brand-new rights that didn't exist as part of a netlink socket before. > > > > Sorry, I don't understand this part. Could you eloborate? Maybe give an > > example. > > > > I always think that it's a feature, that we can create a descriptor and > > drop capabilities of the process or send this descriptor to an > > unprivilieged process. > > Suppose there's an existing program that likes this feature. It > creates a netlink socket, optionally calls connect(2), and then drop > privileges. It expects to retain some subset of its privileges. > > The problem is that by increasing the power of a netlink socket > created with higher-than-current privilege, you've just increased the > privilege retained by the old app. In this particular case, it's > especially odd because it retains privilege over the old pidns, > whereas the old program (in theory -- probably no one does this) could > have created a netlink socket, unshared pidns, and forked, and it > would have expected to retain no privilege over the old pidns. Thank you for the explanation. If I understand you correctly, the problem is that we can use an arbitrary netlink socket to use task_diag. It can be a reason to not use netlink interface for task diag. What do you think about the idea to add a a transaction file in procfs? We will open it, send a request and get required information. I want to have a file descriptor to transfer data between kernel and userspace, because a size of response can be too big to receive it for one call. If we use a file descriptor, we can divide a response into parts. Thanks, Andrew > --Andy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/