From: Andy Lutomirski <luto@amacapital.net>
To: Andrew Vagin <avagin@virtuozzo.com>
Cc: Roger Luethi <rl@hellgate.ch>,
Cyrill Gorcunov <gorcunov@openvz.org>,
Pavel Emelyanov <xemul@parallels.com>,
Andrey Vagin <avagin@openvz.org>,
Pavel Odintsov <pavel.odintsov@gmail.com>,
Andrew Morton <akpm@linux-foundation.org>,
Oleg Nesterov <oleg@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Linux API <linux-api@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
David Ahern <dsahern@gmail.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>
Subject: Re: [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2)
Date: Mon, 14 Dec 2015 14:38:06 -0800 [thread overview]
Message-ID: <CALCETrU_MtDa3p64R5bLx4BU5mKTDD0iEgtA4nLRHPfS2JbhOQ@mail.gmail.com> (raw)
In-Reply-To: <20151214075217.GB4112@odin.com>
On Dec 13, 2015 11:52 PM, "Andrew Vagin" <avagin@virtuozzo.com> 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 <avagin@virtuozzo.com> 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.
--Andy
next prev parent reply other threads:[~2015-12-14 22:38 UTC|newest]
Thread overview: 90+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-06 8:47 [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2) Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 01/24] kernel: define taststats commands in the one place Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 02/24] kernel: add a netlink interface to get information about tasks (v2) Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 03/24] kernel: make taskstats available from all net namespaces Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 04/24] kernel: move next_tgid from fs/proc Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 05/24] task_diag: add ability to get information about all tasks Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 06/24] task_diag: add ability to split per-task data on a few netlink messages Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 07/24] task_diag: add a new group to get process credentials Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 08/24] proc: pick out a function to iterate task children Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-14 18:02 ` Oleg Nesterov
2015-07-14 18:02 ` Oleg Nesterov
2015-07-17 15:57 ` Andrew Vagin
2015-07-17 15:57 ` Andrew Vagin
2015-07-18 21:22 ` Oleg Nesterov
2015-07-18 21:22 ` Oleg Nesterov
2015-07-06 8:47 ` [PATCH 09/24] proc: move task_next_child() from fs/proc Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 10/24] task_diag: add ability to dump children (v2) Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 11/24] task_diag: add a new group to get task statistics Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 12/24] task_diag: add a new group to get tasks memory mappings (v2) Andrey Vagin
2015-07-14 18:08 ` Oleg Nesterov
2015-07-14 18:08 ` Oleg Nesterov
2015-07-15 2:02 ` David Ahern
2015-07-15 2:02 ` David Ahern
2015-07-06 8:47 ` [PATCH 13/24] task_diag: shows memory consumption for " Andrey Vagin
2015-07-06 8:47 ` [PATCH 14/24] task_diag: add a marcos to enumirate memory mappings Andrey Vagin
2015-07-06 8:47 ` [PATCH 15/24] proc: give task_struct instead of pid into first_tid Andrey Vagin
2015-07-14 18:11 ` Oleg Nesterov
2015-07-06 8:47 ` [PATCH 16/24] proc: move first_tid and next_tid out of proc Andrey Vagin
2015-07-06 8:47 ` [PATCH 17/24] task_diag: add ability to dump theads Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 8:47 ` [PATCH 18/24] task_diag: add ability to handle one task in a continious mode Andrey Vagin
2015-07-06 8:47 ` [PATCH 19/24] task_diag: Add option to dump all threads for all tasks Andrey Vagin
2015-07-06 8:47 ` [PATCH 20/24] task_diag: Only add VMAs for thread_group leader Andrey Vagin
2015-07-14 17:47 ` Oleg Nesterov
2015-07-14 17:47 ` Oleg Nesterov
2015-07-15 2:01 ` David Ahern
2015-07-15 13:31 ` Oleg Nesterov
2015-07-15 13:31 ` Oleg Nesterov
2015-07-06 8:47 ` [PATCH 21/24] task diag: Add support for TGID attribute Andrey Vagin
2015-07-06 8:47 ` [PATCH 22/24] Documentation: add documentation for task_diag Andrey Vagin
2015-07-06 8:47 ` [PATCH 23/24] selftest: check the task_diag functinonality Andrey Vagin
2015-07-06 8:47 ` [PATCH 24/24] task_diag: Enhance fork tool to spawn threads Andrey Vagin
2015-07-06 8:47 ` Andrey Vagin
2015-07-06 17:10 ` [PATCH 0/24] kernel: add a netlink interface to get information about processes (v2) Andy Lutomirski
2015-07-07 15:43 ` Andrew Vagin
2015-07-07 15:56 ` Andy Lutomirski
2015-07-07 15:56 ` Andy Lutomirski
2015-07-07 16:17 ` David Ahern
2015-07-07 16:17 ` David Ahern
2015-07-07 16:24 ` Andy Lutomirski
2015-07-07 16:41 ` David Ahern
2015-07-07 16:41 ` David Ahern
2015-07-08 16:10 ` Andrew Vagin
2015-07-08 16:10 ` Andrew Vagin
2015-07-08 17:39 ` Andy Lutomirski
2015-07-08 22:49 ` Andrey Vagin
2015-07-08 23:48 ` Andy Lutomirski
2015-07-08 23:48 ` Andy Lutomirski
2015-07-07 16:25 ` Arnaldo Carvalho de Melo
2015-07-07 16:25 ` Arnaldo Carvalho de Melo
2015-07-07 16:27 ` Andy Lutomirski
2015-07-07 16:27 ` Andy Lutomirski
2015-07-07 16:56 ` David Ahern
2015-07-07 16:56 ` David Ahern
2015-11-24 15:18 ` Andrew Vagin
2015-11-24 15:18 ` Andrew Vagin
2015-12-03 23:20 ` Andy Lutomirski
2015-12-03 23:20 ` Andy Lutomirski
2015-12-03 23:43 ` Arnd Bergmann
2015-12-14 8:05 ` Andrew Vagin
2015-12-14 8:05 ` Andrew Vagin
2015-12-14 7:52 ` Andrew Vagin
2015-12-14 7:52 ` Andrew Vagin
2015-12-14 22:38 ` Andy Lutomirski [this message]
2015-12-15 15:53 ` Andrew Vagin
2015-12-15 15:53 ` Andrew Vagin
2015-12-15 16:43 ` Andy Lutomirski
2015-12-15 16:43 ` Andy Lutomirski
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=CALCETrU_MtDa3p64R5bLx4BU5mKTDD0iEgtA4nLRHPfS2JbhOQ@mail.gmail.com \
--to=luto@amacapital.net \
--cc=acme@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=arnd@arndb.de \
--cc=avagin@openvz.org \
--cc=avagin@virtuozzo.com \
--cc=dsahern@gmail.com \
--cc=gorcunov@openvz.org \
--cc=linux-api@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=pavel.odintsov@gmail.com \
--cc=rl@hellgate.ch \
--cc=xemul@parallels.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.