OK, I've been struggling with this (off and on) since Tuesday, and I give up.
Since going from 2.4.3-pre4 to 2.4.2-ac20 I have been unable to use binfmt_misc.
Thanks to a hint from Michael Meissner, I found a mention in the release notes
for 2.4.2-ac12 that binfmt_misc should be mounted separately. However, I still
have a problem.
The release notes specify this:
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
but this doesn't work because
mount: mount point /proc/sys/fs/binfmt_misc does not exist
And if I try to mkdir -p /proc/sys/fs/binfmt_misc with /proc mounted I get
mkdir: cannot create directory `/proc/sys/fs/binfmt_misc': No such file or
directory
which makes sense, I guess, because proc isn't a "real" filesystem. So how do I
get binfmt_misc mounted?
Wayne
On Fri, 16 Mar 2001 [email protected] wrote:
> The release notes specify this:
>
> mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
>
> but this doesn't work because
>
> mount: mount point /proc/sys/fs/binfmt_misc does not exist
Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
Solutions:
a) mount it on some real place. And write there to register
entries instead of the bogus /proc/sys/fs/binfmt_misc
b) add a couple of proc_mkdir() into fs/proc/root.c
That is, add
proc_mkdir("sys/fs", 0):
proc_mkdir("sys/fs/binfmt_misc", 0);
after the line that says
proc_mkdir("sys", 0);
I would strongly recommend (a). In the long run we'll need to go that
way.
[email protected] wrote:
>
>
> which makes sense, I guess, because proc isn't a "real" filesystem. So how do I
> get binfmt_misc mounted?
mount it somewhere else, say, /dev/binfmt_mount instead of in /proc
until the proc entry is fixed. What should creat
/proc/sys/fs/binfmt_misc ?
-Thomas
Thanks for the quick response. I took your suggestion (a) and created
/etc/binfmt_misc, and set up a test in my rc.local to mount it and register my
usual entries there if /proc/sys/fs/binfmt_misc doesn't exist. So now it works
with both 2.4.3-pre4 and 2.4.2-ac20.
Wayne
Alexander Viro <[email protected]> on 03/16/2001 09:37:49 AM
To: Wayne Brown/Corporate/Altec@Altec
cc: [email protected]
Subject: Re: How to mount /proc/sys/fs/binfmt_misc ?
On Fri, 16 Mar 2001 [email protected] wrote:
> The release notes specify this:
>
> mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
>
> but this doesn't work because
>
> mount: mount point /proc/sys/fs/binfmt_misc does not exist
Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
Solutions:
a) mount it on some real place. And write there to register
entries instead of the bogus /proc/sys/fs/binfmt_misc
b) add a couple of proc_mkdir() into fs/proc/root.c
That is, add
proc_mkdir("sys/fs", 0):
proc_mkdir("sys/fs/binfmt_misc", 0);
after the line that says
proc_mkdir("sys", 0);
I would strongly recommend (a). In the long run we'll need to go that
way.
On Fri, 16 Mar 2001, Alexander Viro wrote:
> On Fri, 16 Mar 2001 [email protected] wrote:
>
> > The release notes specify this:
> >
> > mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
> >
> > but this doesn't work because
> >
> > mount: mount point /proc/sys/fs/binfmt_misc does not exist
>
> Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
>
> Solutions:
> a) mount it on some real place. And write there to register
> entries instead of the bogus /proc/sys/fs/binfmt_misc
> b) add a couple of proc_mkdir() into fs/proc/root.c
c) stick with the previous binfmt_misc in 2.4 and leave the
filesystem with 2.5
Richard.
--
Richard Guenther <[email protected]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/
On Fri, 16 Mar 2001, Richard Guenther wrote:
> On Fri, 16 Mar 2001, Alexander Viro wrote:
> > On Fri, 16 Mar 2001 [email protected] wrote:
> >
> > > The release notes specify this:
> > >
> > > mount -t binfmt_misc none /proc/sys/fs/binfmt_misc
> > >
> > > but this doesn't work because
> > >
> > > mount: mount point /proc/sys/fs/binfmt_misc does not exist
> >
> > Grr... OK, I've been an overoptimistic idiot and missed that ugliness.
> >
> > Solutions:
> > a) mount it on some real place. And write there to register
> > entries instead of the bogus /proc/sys/fs/binfmt_misc
> > b) add a couple of proc_mkdir() into fs/proc/root.c
> c) stick with the previous binfmt_misc in 2.4 and leave the
> filesystem with 2.5
Sure. With all its holes and illetarate C.
On Fri, 16 Mar 2001, Alexander Viro wrote:
[snip]
> Sure. With all its holes and illetarate C.
^
e
Apparently, rule about typos in spelling flame are not
limited to natural languages...
On Fri, Mar 16, 2001 at 01:07:17PM -0500, Alexander Viro wrote:
>
>
> On Fri, 16 Mar 2001, Alexander Viro wrote:
>
> [snip]
>
> > Sure. With all its holes and illetarate C.
> ^
> e
> Apparently, rule about typos in spelling flame are not
> limited to natural languages...
Oh... Was it a typo? I had a good laugh, because I thought it was
intended. Especially considering that you left one of the typos
(I was always taught that it's spelled illiterate...)
/David Weinehall
_ _
// David Weinehall <[email protected]> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
On Fri, 16 Mar 2001, David Weinehall wrote:
> On Fri, Mar 16, 2001 at 01:07:17PM -0500, Alexander Viro wrote:
> >
> >
> > On Fri, 16 Mar 2001, Alexander Viro wrote:
> >
> > [snip]
> >
> > > Sure. With all its holes and illetarate C.
> > ^
> > e
> > Apparently, rule about typos in spelling flame are not
> > limited to natural languages...
>
> Oh... Was it a typo? I had a good laugh, because I thought it was
> intended. Especially considering that you left one of the typos
> (I was always taught that it's spelled illiterate...)
Original - typo, the rest (including "rule...are") - not ;-)
Seriously, binfmt_misc.c was written in rather, erm, interesting C.
Read it and you'll see. Just one (but rather impressive) example:
if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
It was meant to be
if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
and anyone who can't find the difference really should learn C. And
that's not the only bogosity of such level. Besides, the thing is
trivially oopsable - write() to any file in binfmt_misc with buffer
pointing to unmapped kernel address and you are screwed,
Alexander Viro <[email protected]> wrote:
>Seriously, binfmt_misc.c was written in rather, erm, interesting C.
>Read it and you'll see. Just one (but rather impressive) example:
>
> if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
>
>It was meant to be
>
> if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
>
>and anyone who can't find the difference really should learn C. And
>that's not the only bogosity of such level. Besides, the thing is
>trivially oopsable - write() to any file in binfmt_misc with buffer
>pointing to unmapped kernel address and you are screwed,
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.
--
Colin Watson [[email protected]]
On Mon, 19 Mar 2001, Colin Watson wrote:
> Alexander Viro <[email protected]> wrote:
> >Seriously, binfmt_misc.c was written in rather, erm, interesting C.
> >Read it and you'll see. Just one (but rather impressive) example:
> >
> > if ((count == 1) && !(buffer[0] & ~('0' | '1'))) {
> >
> >It was meant to be
> >
> > if (count == 1 && (buffer[0] == '0' || buffer[0] == '1')) {
> >
> >and anyone who can't find the difference really should learn C. And
> >that's not the only bogosity of such level. Besides, the thing is
> >trivially oopsable - write() to any file in binfmt_misc with buffer
> >pointing to unmapped kernel address and you are screwed,
>
> 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!?
Richard.
--
Richard Guenther <[email protected]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/
> > a) mount it on some real place. And write there to register
> > entries instead of the bogus /proc/sys/fs/binfmt_misc
> > b) add a couple of proc_mkdir() into fs/proc/root.c
> c) stick with the previous binfmt_misc in 2.4 and leave the
> filesystem with 2.5
Actually you would still need the other fixes otherwise you might as well put
the root password in /etc/motd
Richard Guenther <[email protected]> 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 [[email protected]]
On Thu, 22 Mar 2001, Colin Watson wrote:
> 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.
Actually, the right thing to do would be to drop the ugly tricks with
writing to .../register and use normal create()/write()/close() to add
entries. Commit-on-close and there you go. unlink() to remove these
suckers, chmod g-r to disable.
IOW, instead of
echo ':foo:.......' >register echo ':.....' > /etc/binfmt_misc/foo
echo '-1' > foo rm /etc/binfmt_misc/foo
echo '0' > foo chmod g-r /etc/binfmt_misc/foo
echo '1' > foo chmod g+r /etc/binfmt_misc/foo
echo '-1' > status rm /etc/binfmt_misc/*
echo '0' > status chmod -x /etc/binfmt_misc
echo '1' > status chmod +x /etc/binfmt_misc
cat status cat /etc/binfmt_misc/*
Normal behaviour instead of black magic, no checks for duplicate entries,
special names, yodda, yodda - everything would work as one expects from
normal directory. When you want to create a file you create it, not write
an incantation into a magic file. And when you want to remove it, the
last thing you would normally think of is writing "-1" into the victim.
Yes, I know that procfs doesn't allow that. Mark the correct conclusion:
(A) procfs is not suitable for the task
(B) we should invent a kludgy way to create files, etc. on
procfs without using normal create() and reimplement the
sanity checks
(C) same as (B), but ignore sanity
Your choice being...?
And yes, I'm quite aware of the fact that we are stuck with the current
kludgy API - compatibility issues and all such. Pity, that...
Al, very unimpressed both with design and implementation of that kludge...
On Thu, 22 Mar 2001, Alexander Viro wrote:
> Actually, the right thing to do would be to drop the ugly tricks with
> writing to .../register and use normal create()/write()/close() to add
> entries. Commit-on-close and there you go. unlink() to remove these
> suckers, chmod g-r to disable.
>
> IOW, instead of
> echo ':foo:.......' >register echo ':.....' > /etc/binfmt_misc/foo
> echo '-1' > foo rm /etc/binfmt_misc/foo
> echo '0' > foo chmod g-r /etc/binfmt_misc/foo
> echo '1' > foo chmod g+r /etc/binfmt_misc/foo
> echo '-1' > status rm /etc/binfmt_misc/*
> echo '0' > status chmod -x /etc/binfmt_misc
> echo '1' > status chmod +x /etc/binfmt_misc
> cat status cat /etc/binfmt_misc/*
>
> Normal behaviour instead of black magic, no checks for duplicate entries,
> special names, yodda, yodda - everything would work as one expects from
> normal directory. When you want to create a file you create it, not write
> an incantation into a magic file. And when you want to remove it, the
> last thing you would normally think of is writing "-1" into the victim.
> Yes, I know that procfs doesn't allow that. Mark the correct conclusion:
> (A) procfs is not suitable for the task
> (B) we should invent a kludgy way to create files, etc. on
> procfs without using normal create() and reimplement the
> sanity checks
> (C) same as (B), but ignore sanity
> Your choice being...?
My choice would have been (A) if there was a nice way to create small
filesystems at the time I did binfmt_misc. This is also the reason I
dont like your rewrite - it does the same sucky kludges, but with an
own filesystem that could do a lot better - _and_ it breaks
backward compatibility wrt mounting. Doh - I thought you could do
better.
> And yes, I'm quite aware of the fact that we are stuck with the current
> kludgy API - compatibility issues and all such. Pity, that...
>
> Al, very unimpressed both with design and implementation of that kludge...
The first version was w/o /proc support but used sysctl and a userspace
program. But well, people wantet /proc and /proc was sexy, everything
was done using /proc, so I did use it, too. Bad decision - I should have
started rewriting the fs layer at that time...
Richard.
--
Richard Guenther <[email protected]>
WWW: http://www.anatom.uni-tuebingen.de/~richi/
The GLAME Project: http://www.glame.de/