public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: ebiederm@xmission.com (Eric W. Biederman)
To: Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com>
Cc: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>,
	linux-api@vger.kernel.org, linux-kernel@vger.kernel.org,
	Jann Horn <jannh@google.com>,
	Serge Hallyn <serge.hallyn@ubuntu.com>,
	Oleg Nesterov <oleg@redhat.com>,
	Andy Lutomirski <luto@amacapital.net>,
	Prakash Sangappa <prakash.sangappa@oracle.com>,
	Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH RFC v5] pidns: introduce syscall translate_pid
Date: Wed, 04 Apr 2018 17:29:30 -0500	[thread overview]
Message-ID: <87h8oqhagl.fsf@xmission.com> (raw)
In-Reply-To: <ba7b704f-1fc4-a08d-e7cf-2766160bd419@oracle.com> (Nagarathnam Muthusamy's message of "Wed, 4 Apr 2018 13:31:32 -0700")

Nagarathnam Muthusamy <nagarathnam.muthusamy@oracle.com> 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.

>> 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.

Eric

  reply	other threads:[~2018-04-04 22:30 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-04-04 19:11 [PATCH RFC v5] pidns: introduce syscall translate_pid Konstantin Khlebnikov
2018-04-04 20:31 ` Nagarathnam Muthusamy
2018-04-04 22:29   ` Eric W. Biederman [this message]
2018-04-05  7:02     ` Konstantin Khlebnikov
2018-04-23 17:37       ` Nagarathnam Muthusamy
2018-04-25  5:36         ` Konstantin Khlebnikov
2018-05-15 17:19           ` Nagarathnam Muthusamy
2018-05-15 17:36             ` Konstantin Khlebnikov
2018-05-15 17:40               ` Nagarathnam Muthusamy
2018-05-15 17:44                 ` Nagarathnam Muthusamy
2018-05-31 17:41               ` Nagarathnam Muthusamy
2018-05-31 17:52                 ` Eric W. Biederman
2018-05-31 18:05                 ` Eric W. Biederman
2018-06-01  6:58                   ` Konstantin Khlebnikov
2018-06-01 15:55                     ` NAGARATHNAM MUTHUSAMY
2018-06-01 16:14                       ` Eric W. Biederman
2018-06-01 16:15                       ` Konstantin Khlebnikov
2018-04-27 12:15       ` Michael Kerrisk (man-pages)
2018-05-31 18:02         ` 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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=87h8oqhagl.fsf@xmission.com \
    --to=ebiederm@xmission.com \
    --cc=akpm@linux-foundation.org \
    --cc=jannh@google.com \
    --cc=khlebnikov@yandex-team.ru \
    --cc=linux-api@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@amacapital.net \
    --cc=nagarathnam.muthusamy@oracle.com \
    --cc=oleg@redhat.com \
    --cc=prakash.sangappa@oracle.com \
    --cc=serge.hallyn@ubuntu.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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