From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Cyrus-Session-Id: sloti22d1t05-2967706-1526405089-2-17368611890325053534 X-Sieve: CMU Sieve 3.0 X-Spam-known-sender: no ("Email failed DMARC policy for domain") X-Spam-score: 0.0 X-Spam-hits: BAYES_00 -1.9, HEADER_FROM_DIFFERENT_DOMAINS 0.249, MAILING_LIST_MULTI -1, RCVD_IN_DNSWL_HI -5, LANGUAGES en, BAYES_USED global, SA_VERSION 3.4.0 X-Spam-source: IP='209.132.180.67', Host='vger.kernel.org', Country='US', FromHeader='com', MailFrom='org' X-Spam-charsets: plain='utf-8' X-IgnoreVacation: yes ("Email failed DMARC policy for domain") X-Resolved-to: greg@kroah.com X-Delivered-to: greg@kroah.com X-Mail-from: linux-api-owner@vger.kernel.org ARC-Seal: i=1; a=rsa-sha256; cv=none; d=messagingengine.com; s=fm2; t= 1526405088; b=gQ96ETendDBsS7RRbiQve1Ak9BV15LZ7DSVOiL3pN17gFgtzT0 rkr5W8Y/XjS3zl8EpUf4kuHlhp9my7LoN0h+kkSdcQVbfetuIOfZxxVJIwcmkDRH ZmcrypQwvlP+FME0293K47zUc28jelFdK70X45tsGX78Vhi8WjjiMWBg/HVzWQn9 mKBt2rPYcdHCLSiyaqtzaaveIesnWvSDJgF4SXRVW3yaW+eeaXC9RqjioqOFOPK3 vHz654wgHN+u2vMDXaNQ3OC+2VtjAeN17WSuI07KcS7/nPVpQJWIngpLiJmRNhZI 3oszvW2SbGtqvNfhZnEsIc1oy//JIXFFZ70w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=subject:to:cc:references:from:message-id :date:mime-version:in-reply-to:content-type :content-transfer-encoding:sender:list-id; s=fm2; t=1526405088; bh=5htMnUfUsNklt3zAmXhPoYfYCWfsMIcBAXJA69mkQiw=; b=ieSFjtawjHex AdTynm4pYGrfnZRl/lzjobWZ2yYf0oEm1SvHANv4uWwLTZ5oXUDzCqIg68nFVi2n r+Bll3U6Ug4EfqYY+RWBiEpATG6YayACbZeyNQpBc5nwaP2YNlwFZJzU91cvoq27 7g0mi8TrFd+eTe3uv5q9Uw6vDfPxUwpY2UQJQXfhAYLz4mk9RRnEUm4yAlAJYpgV ZYZHOBqqk8SaW37Y+s86nz5h3dLwwbICDrCrQxrwb+2JzyWOfNDgSHNH4vVtNyr4 ZHmjksweZyfcA0eALki4bSwQggSTswybsAoGBusFuqei/He5d9qwv6r1tgHUXNVp DU8gNJh7xQ== ARC-Authentication-Results: i=1; mx6.messagingengine.com; arc=none (no signatures found); dkim=fail (body has been altered, 2048-bit rsa key sha256) header.d=oracle.com header.i=@oracle.com header.b=W2xTBqFG x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=corp-2017-10-26; dmarc=fail (p=none,has-list-id=yes,d=none) header.from=oracle.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=oracle.com header.result=pass header_is_org_domain=yes; x-vs=clean score=-100 state=0 Authentication-Results: mx6.messagingengine.com; arc=none (no signatures found); dkim=fail (body has been altered, 2048-bit rsa key sha256) header.d=oracle.com header.i=@oracle.com header.b=W2xTBqFG x-bits=2048 x-keytype=rsa x-algorithm=sha256 x-selector=corp-2017-10-26; dmarc=fail (p=none,has-list-id=yes,d=none) header.from=oracle.com; iprev=pass policy.iprev=209.132.180.67 (vger.kernel.org); spf=none smtp.mailfrom=linux-api-owner@vger.kernel.org smtp.helo=vger.kernel.org; x-aligned-from=fail; x-cm=none score=0; x-ptr=pass x-ptr-helo=vger.kernel.org x-ptr-lookup=vger.kernel.org; x-return-mx=pass smtp.domain=vger.kernel.org smtp.result=pass smtp_org.domain=kernel.org smtp_org.result=pass smtp_is_org_domain=no header.domain=oracle.com header.result=pass header_is_org_domain=yes; x-vs=clean score=-100 state=0 X-ME-VSCategory: clean X-CM-Envelope: MS4wfJb1hLn2O3uZN4OBLXUSnS0oS3OdDLzQ8400pN2R8t7saN0XbIu+qsDvpUVF0FuAorUclcXbM6ZeH01ocN0Wn25+ebe16hbIbF0oO94OjezcElrhP9IX GmF6X2W25vNPlSfybVXYtFE7nKkvy+ocaYgZw4Qn2A/DSR85VXZDOs8HCAzeMGrf2xb9hNhjyKuYBXRRl6/vBUUOjR8y/4MBGVbbtpYZcgxsnsKe1XoDWoEF X-CM-Analysis: v=2.3 cv=FKU1Odgs c=1 sm=1 tr=0 a=UK1r566ZdBxH71SXbqIOeA==:117 a=UK1r566ZdBxH71SXbqIOeA==:17 a=IkcTkHD0fZMA:10 a=VUJBJC2UJ8kA:10 a=yPCof4ZbAAAA:8 a=D19gQVrFAAAA:8 a=NEAV23lmAAAA:8 a=VwQbUJbxAAAA:8 a=d8RV8bvci-gWPrTDWUkA:9 a=Z71ZVNYPjp4KbPUM:21 a=hjeekhAMHtmOMyMa:21 a=QEXdDO2ut3YA:10 a=x8gzFH9gYPwA:10 a=W4TVW4IDbPiebHqcZpNg:22 a=AjGcO6oz07-iQ99wixmX:22 X-ME-CMScore: 0 X-ME-CMCategory: none Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932143AbeEORYp (ORCPT ); Tue, 15 May 2018 13:24:45 -0400 Received: from userp2130.oracle.com ([156.151.31.86]:46338 "EHLO userp2130.oracle.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754201AbeEORYo (ORCPT ); Tue, 15 May 2018 13:24:44 -0400 Subject: Re: [PATCH RFC v5] pidns: introduce syscall translate_pid To: Konstantin Khlebnikov , "Eric W. Biederman" Cc: linux-api@vger.kernel.org, linux-kernel@vger.kernel.org, Jann Horn , Serge Hallyn , Oleg Nesterov , Andy Lutomirski , Prakash Sangappa , Andrew Morton References: <152286911105.615669.14053871624892399807.stgit@buzz> <87h8oqhagl.fsf@xmission.com> <112c7cac-1982-3a2e-ffc0-878bc5ae4bb6@yandex-team.ru> <778ab3d0-b6bc-fdb5-669a-40222e5020d4@yandex-team.ru> From: Nagarathnam Muthusamy Message-ID: Date: Tue, 15 May 2018 10:19:03 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <778ab3d0-b6bc-fdb5-669a-40222e5020d4@yandex-team.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Proofpoint-Virus-Version: vendor=nai engine=5900 definitions=8894 signatures=668698 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=17 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1711220000 definitions=main-1805150172 Sender: linux-api-owner@vger.kernel.org X-Mailing-List: linux-api@vger.kernel.org X-getmail-retrieved-from-mailbox: INBOX X-Mailing-List: linux-kernel@vger.kernel.org List-ID: On 04/24/2018 10:36 PM, Konstantin Khlebnikov wrote: > On 23.04.2018 20:37, Nagarathnam Muthusamy wrote: >> >> >> On 04/05/2018 12:02 AM, Konstantin Khlebnikov wrote: >>> On 05.04.2018 01:29, Eric W. Biederman wrote: >>>> Nagarathnam Muthusamy writes: >>>> >>>>> On 04/04/2018 12:11 PM, Konstantin Khlebnikov wrote: >>>>>> Each process have different pids, one for each pid namespace it >>>>>> belongs. >>>>>> When interaction happens within single pid-ns translation isn't >>>>>> required. >>>>>> More complicated scenarios needs special handling. >>>>>> >>>>>> For example: >>>>>> - reading pid-files or logs written inside container with pid >>>>>> namespace >>>>>> - attaching with ptrace to tasks from different pid namespace >>>>>> - passing pids across pid namespaces in any kind of API >>>>>> >>>>>> Currently there are several interfaces that could be used here: >>>>>> >>>>>> Pid namespaces are identified by inode number of /proc/[pid]/ns/pid. >>>> >>>> Using the inode number in interfaces is not an option. Especially not >>>> withou referencing the device number for the filesystem as well. >>> >>> This is supposed to be single-instance fs, >>> not part of proc but referenced but its magic "symlinks". >>> >>> Device numbers are not mentioned in "man namespaces". >>> >>>> >>>>>> Pids for nested Pid namespaces are shown in file /proc/[pid]/status. >>>>>> In some cases conversion pid -> vpid could be easily done using this >>>>>> information, but backward translation requires scanning all tasks. >>>>>> >>>>>> Unix socket automatically translates pid attached to >>>>>> SCM_CREDENTIALS. >>>>>> This requires CAP_SYS_ADMIN for sending arbitrary pids and entering >>>>>> into pid namespace, this expose process and could be insecure. >>>>>> >>>>>> This patch adds new syscall for converting pids between pid >>>>>> namespaces: >>>>>> >>>>>> pid_t translate_pid(pid_t pid, int source_type, int source, >>>>>>                                  int target_type, int target); >>>>>> >>>>>> @source_type and @target_type defines type of following arguments: >>>>>> >>>>>> TRANSLATE_PID_CURRENT_PIDNS  - current pid namespace, argument is >>>>>> unused >>>>>> TRANSLATE_PID_TASK_PIDNS     - task pid-ns, argument is task pid >>>>> >>>>> I believe using pid to represent the namespace has been already >>>>> discussed in V1 of this patch in https://lkml.org/lkml/2015/9/22/1087 >>>>> after which we moved on to fd based version of this interface. >>>> >>>> Or in short why is the case of pids important? >>>> >>>> You Konstantin you almost said why they were important in your message >>>> saying you were going to send this one.  However you don't explain in >>>> your description why you want to identify pid namespaces by pid. >>>> >>> >>> Open of /proc/[pid]/ns/pid requires same permissions as ptrace, >>> pid based variant doesn't have such restrictions. >> >> Can you provide more information on usecase requiring PID translation >> but not used for tracing related purposes? > > Any introspection for [nested] containers. It's easier to work when > you have all information when you don't have any. > For example our CMS https://github.com/yandex/porto allows to start > nested sub-container (or even deeper) by request from any container > and have to tell back which pid task is have. And it could translate > any pid inside into accessible by client and vice versa. > I still dont get the exact reason why PID based approach to identify the namespace during pid translation process is absolutely required compared to fd based approach. From your version of TranslatePid in https://github.com/yandex/porto/blob/0d7e6e7e1830dcd0038a057b2ab9964cec5b8fab/src/util/unix.cpp I see that you are going through the trouble of forking a process and sending SMC_CREDENTIALS for pid translation. Even your existing API could be extremely simplified if translate_pid based on file descriptors make it to the gate and I believe from the last discussion it was almost there https://patchwork.kernel.org/patch/10305439/ >> On a side note, can we have the types TRANSLATE_PID_CURRENT_PIDNS and >> TRANSLATE_PID_FD_PIDNS integrated first and then possibly extend the >> interface to include TRANSLATE_PID_TASK_PIDNS in future? > > I don't see reason for this separation. > Pids and pid namespaces are part of the API for a long time. If you are talking about the translate_pid API proposed, I believe the V4 proposed under https://patchwork.kernel.org/patch/10003935/ had only fd based API before a mix of PID and fd based is proposed in V5. Again, I was just wondering if we can get the FD based approach in first and then extend the API to include PID based approach later as fd based approach could provide a lot of immediate benefits? Thanks, Nagarathnam. > >> >> Thanks, >> Nagarathnam. >>> Most pid-based syscalls are racy in some cases but they are >>> here for decades and everybody knowns how to deal with it. >>> So, I've decided to merge both worlds in one interface which clearly >>> tells what to expect. >>