Re: Suggestion: binfmt_misc handling
On Mon, Oct 04, 1999 at 09:37:02AM +1000, Brian May was heard to say:
> > Packages such as Wine, Kaffe, dosemu, and perhaps Frotz would drop a file
> >into this directory announcing their support of a binary format. The files
> >wouldn't actually be interpreted unless this init.d script is installed; I
> >assume that someone is going to claim this is a security hazard, so I thought
> >I'd point that out :P
> I have two comments:
> 1. Where would you install the files into this directory?
> Ideally, IMHO, it would be possible to directly embed the config file
> into the deb file, with the full pathname under /etc/bin_fmt.
> However, in this case, what would happen with duplicates? eg what will
> happen when many packages that provide Java, all provide their own
> (possibly different) entry under /etc/bin_fmt?
A problem. Clearly I haven't thought deeply about this..I just turned up
the script on my system, said "wow, that was a good idea!" and sent it here for
comments. I like your comments, though:
> 2. Suggestion: Would it be possible to somehow integrate this with
> /etc/mailcap, which already has good support in packages? There are
> different ways you could do this, eg have in the config file lines that
> look like:
> Where the last field is replaced with the appropriate command line from
> the /etc/mailcap file. Not that there currently is a mailcap entry (at
> least on my slink system) for java...
> This file could potentially be used for more applications then just the
> kernel - any program that wants to map the file to a MIME type. (Apache
> already does this - is this any better? I suspect Apache's is hardcoded,
> but not sure).
> I think that this could be done with similar structure as originally
This is much better than what I had. I've had another suggestion to use
mailcap as well, and I think this is a good idea -- but I'm not quite sure how
to make it work in Linux (Marcus suggested something like this in the Hurd). I
think, though, that what's put in the binfmt_misc database should be restricted:only things that vaguely resemble a program should go into it. One possibility
is a meta-config file:
type "Java programs"
or, more interestingly:
application/x-java; kaffe %s; magic-number="0xCAFEBABE"; \
(this is the format used by update-mime)
Assume that update-mime was changed to handle this. For every MIME type for
which a MIME handler declared "executable=true", update-mime would dump an
entry to /etc/binfmt_misc with instructions to use the handler which was the
highest priority of those which declared themselves to be willing to execute
files of that type.
update-mime could also check the architecture it's running on and do something
different on the Hurd, once it's decided exactly how that system will handle
stuff like this.
Does this sound reasonable?
Genius may have its limitations, but stupidity is not thus handicapped.
-- Elbart Hubbard