[CC to -emulation as well]
Matthew Dillon wrote:
>
> I just noticed that the reserved area of the user stack that the linux
> emulator uses to copy modified paths is only 256 bytes long.
>
> linux_rename() makes two calls to the path munging code, which means
> that the two path arguments are limited in aggregate to 256 bytes,
> which is wrong.
I've kept a PR open that addresses this indirectly. The real bug is that
there's no length checking, which means that if the combined length
exceeds 256, bad things happen.
> I've also noted another major issue with the linux emulation, and that
> is with shell script execution.
>
> If you are running a linux binary which then fork/exec's a shell script,
> the interpreter path at the top of the shell script does not undergo
> the path munging code, which breaks the script out of the linux emulation
> mode (because it runs the FreeBSD /bin/sh, /bin/csh, etc instead of the
> linux version).
This is something I have on my TODO list for a while now.
> I have a fix for the latter problem. It's fairly trivial.
> Without a fix the only way one can reliably run serious linux apps
> (like an oracle install for example) under linux emulation is to
> chroot into /compat/linux. I would appreciate a review:
It basicly looks all right. I haven't tried it yet and also didn't study
it closely. I was thinking along the lines of creating more of a
"context". This way we can have different behaviour depending on
"context". Context being "FreeBSD" or "Linux" or whatever. I hoped to
save the addition of "try-this-first" pointers to existing structures.
Not that it is bad in general, but I somehow always end up thinking that
there's something structurally wrong if you end up doing it like that
:-)
> (No, this fix alone isn't enough to do an oracle install, it's just too
> grungy a beast).
In 1999Q2 I did an install of Oracle8i, which failed due to an installer
problem, IIRC. I only modified 1 script to overcome the shell execution
problem. You are using Blackdown JDK, are you?
--
Marcel Moolenaar
mail: [EMAIL PROTECTED] / [EMAIL PROTECTED]
tel: (408) 447-4222
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message