From owner-freebsd-emulation Mon Apr 10 9:40:15 2000 Delivered-To: freebsd-emulation@freebsd.org Received: from atlrel2.hp.com (atlrel2.hp.com [156.153.255.202]) by hub.freebsd.org (Postfix) with ESMTP id A3CAA37BC11; Mon, 10 Apr 2000 09:40:11 -0700 (PDT) (envelope-from marcel@cup.hp.com) Received: from adlmail.cup.hp.com (adlmail.cup.hp.com [15.0.100.30]) by atlrel2.hp.com (Postfix) with ESMTP id 1E423A53; Mon, 10 Apr 2000 12:40:09 -0400 (EDT) Received: from cup.hp.com (gauss.cup.hp.com [15.28.97.152]) by adlmail.cup.hp.com with ESMTP (8.8.6 (PHNE_17135)/8.7.3 TIS 5.0.1) id JAA18919; Mon, 10 Apr 2000 09:40:08 -0700 (PDT) Message-ID: <38F203E8.B6F49F98@cup.hp.com> Date: Mon, 10 Apr 2000 09:40:08 -0700 From: Marcel Moolenaar Organization: Hewlett-Packard X-Mailer: Mozilla 4.72 [en] (X11; I; Linux 2.2.12 i386) X-Accept-Language: en MIME-Version: 1.0 To: Matthew Dillon Cc: freebsd-current@FreeBSD.ORG, freebsd-emulation@FreeBSD.ORG Subject: Re: linux emulation problems - path length restrictions in linux_rename References: <200004081855.LAA11984@apollo.backplane.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-emulation@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org [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: marcel@cup.hp.com / marcel@FreeBSD.org tel: (408) 447-4222 To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-emulation" in the body of the message