Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1578518 > unrolled thread

Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs  hidepid= field Lafcadio Wluiki <wluikil@gmail.com> - 2017-02-10 15:50 +0100
    Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs  hidepid= field Andy Lutomirski <luto@amacapital.net> - 2017-02-10 19:20 +0100

#1578518 — Re: [PATCH v4 2/2] procfs/tasks: add a simple per-task procfs hidepid= field

On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski <luto@amacapital.net> wrote:

> I agree that the kernel change to do it per task is very simple.  But
> this is an unfortunate slippery slope.  What if you want to block off
> everything in /proc that isn't associated with a PID?  What if you
> want to suppress /sys access?  What if you want ot block *all*
> non-current PIDs from being revealed in /proc?  What if you want to
> hide /proc/PID/cmdline?

These are all what-ifs that noone was interested in so far. I have a
very specific itch I want to scratch, and I found a reasonably generic
concept of exposing it. But now you are trying to lead this all down
onto a paths asking for features noone is actually really interested
in.

> I think that the right solution here is to fix procfs to understand
> per-superblock mount options.

Andy, this is really not helpful. Doing that is far from easy, that's
a major undertaking: asking us to rework procfs in such a major way I
only can understand as an indirect way for you to say "go away" to
us... Expecting newcomers to kernel work to basically clean up an
entire kernel subsystem, dealing with all the politics involved is
just not going to work.

And again: I am very sure the proposed prctl() based solution is
actually much much nicer than any procfs superblock based one, since
it works naturally, and easily for unprivileged processes too!
Anything that requires mount options means privileges are required in
some form or another. Yes userns would open that up, but that comes
with a huge amount of additional problems.

Anyway, I understand it is your intention to derail this. I can accept
that. It's a pity though.

L.

[toc] | [next] | [standalone]

#1578678

On Fri, Feb 10, 2017 at 6:40 AM, Lafcadio Wluiki <wluikil@gmail.com> wrote:
> On Sat, Jan 21, 2017 at 1:53 AM, Andy Lutomirski <luto@amacapital.net> wrote:
>
>> I agree that the kernel change to do it per task is very simple.  But
>> this is an unfortunate slippery slope.  What if you want to block off
>> everything in /proc that isn't associated with a PID?  What if you
>> want to suppress /sys access?  What if you want ot block *all*
>> non-current PIDs from being revealed in /proc?  What if you want to
>> hide /proc/PID/cmdline?
>
> These are all what-ifs that noone was interested in so far. I have a
> very specific itch I want to scratch, and I found a reasonably generic
> concept of exposing it. But now you are trying to lead this all down
> onto a paths asking for features noone is actually really interested
> in.

If you have an itch and want to scratch it by adding a new API, the
API has to be right, full stop.

>
>> I think that the right solution here is to fix procfs to understand
>> per-superblock mount options.
>
> Andy, this is really not helpful. Doing that is far from easy, that's
> a major undertaking: asking us to rework procfs in such a major way I
> only can understand as an indirect way for you to say "go away" to
> us... Expecting newcomers to kernel work to basically clean up an
> entire kernel subsystem, dealing with all the politics involved is
> just not going to work.

Once upon a time, a newbish kernel hacker named Andy wrote some code
to change the way the vDSO worked.  The maintainers told me that it
was a nice thought and that it was too messy and wasn't acceptable in
its present form.  So the patchset got quite a bit longer, I learned
more about the mess that was the vDSO, and I fixed it.  The
maintainers were right.

It's just not the case that a newcomer gets to add fields to
task_struct that a more experienced developer wouldn't get to add.
Sorry.

>
> And again: I am very sure the proposed prctl() based solution is
> actually much much nicer than any procfs superblock based one, since
> it works naturally, and easily for unprivileged processes too!
> Anything that requires mount options means privileges are required in
> some form or another. Yes userns would open that up, but that comes
> with a huge amount of additional problems.

If you want to design a generic mechanism by which a task can change
the way that pseudo filesystems look for itself and its children
without using mount options, and you come up with something that is
sane, safe, generic, and reasonable clean, you're welcome to do so.
This sounds like a considerably more challenging undertaking than just
fixing procfs.

>
> Anyway, I understand it is your intention to derail this. I can accept
> that. It's a pity though.

I have no intention of derailing improvements to hidepid.  In fact,
I'd love to see improvements here.  I'm just saying that the current
proposal isn't the way to do it.

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web