mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: cjw44@flatline.org.uk (Colin Watson)
To: Richard Guenther <richard.guenther@student.uni-tuebingen.de>
Cc: Linux Kernel List <linux-kernel@vger.kernel.org>
Subject: Re: How to mount /proc/sys/fs/binfmt_misc ?
Date: Thu, 22 Mar 2001 18:28:30 +0000	[thread overview]
Message-ID: <E14g9p0-0005yj-00@riva.ucam.org> (raw)
In-Reply-To: <Pine.LNX.4.30.0103201108440.595-100000@fs1.dekanat.physik.uni-tuebingen.de>
In-Reply-To: <Pine.LNX.4.30.0103201108440.595-100000@fs1.dekanat.physik.uni-tuebingen.de>

Richard Guenther <richard.guenther@student.uni-tuebingen.de> wrote:
>On Mon, 19 Mar 2001, Colin Watson wrote:
>> Or you can register binfmt names that are registered already and
>> silently shadow old ones, or register names like 'register', 'status',
>> '.', and '..'. It's hideous to manage reliably from userspace.
>
>I know you have sent me patches to prevent multiple entries of the
>same name some time ago and I can see we argued about it. The main
>point I have with such checks is, that we dont prevent root from
>doing rm -Rf / either. There is no reason to clobber the kernel with
>endless checks of such cornercases (which even dont make the system
>unusable, but only one (unimportant) part of it). There is even one
>truely nasty "exploit" of binfmt_misc, if you register an entry
>that catches standard elf programs and do module insertion of the
>elf and misc handler in the right order... how would you catch this!?

Indeed, you can't, certainly not easily. I realize there are lots of
ways root can shoot himself in the foot no matter what you do. However,
I don't think that this is a good reason not to do some fairly
elementary consistency checks (just because root can break things one
way is no reason not to try to prevent other mistakes, and I'm also
trying to export a consistent and vaguely reliable interface to other
packages).

I would very much like to be able to assume that a filesystem never
contains two identical filenames linking to different inodes, and that
any . and .. links I find always point to things that are vaguely like
directories! I realize that you can't assume much about /proc, and that
the kernel shouldn't spend forever checking it, but I would hope that
it's generally expected to conform to basic rules of sanity. I'd like my
binfmt_misc management tool to be able to say "OK, beware that you can
screw up your system with this - but if you ask me for a status report
I'll be able to deliver the right answer". That's what I mean by "manage
reliably". As it is, I can only guarantee that I'll give the right
answer to status reports or be able to successfully register and
unregister even sane binary formats if my program is the only interface
being used to binfmt_misc, and I'm not doing any expensive checks.

-- 
Colin Watson                                     [cjw44@flatline.org.uk]

  reply	other threads:[~2001-03-22 18:22 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-03-16 15:23 Wayne.Brown
2001-03-16 15:37 ` Alexander Viro
2001-03-16 17:49   ` Richard Guenther
2001-03-16 17:58     ` Alexander Viro
2001-03-16 18:07       ` Alexander Viro
2001-03-16 18:32         ` David Weinehall
2001-03-16 18:48           ` Alexander Viro
2001-03-19 19:29             ` Colin Watson
2001-03-20 10:12               ` Richard Guenther
2001-03-22 18:28                 ` Colin Watson [this message]
2001-03-22 19:07                   ` Alexander Viro
2001-03-23  9:34                     ` Richard Guenther
2001-03-21 19:18     ` Alan Cox
2001-03-16 16:02 ` Thomas Dodd
2001-03-16 16:12 Wayne.Brown

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=E14g9p0-0005yj-00@riva.ucam.org \
    --to=cjw44@flatline.org.uk \
    --cc=linux-kernel@vger.kernel.org \
    --cc=richard.guenther@student.uni-tuebingen.de \
    /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

all inboxes | Powered by JetHome®