From mboxrd@z Thu Jan 1 00:00:00 1970 From: Mike McCarty Subject: Re: cannot map temp file pool Date: Wed, 20 Sep 2006 12:11:00 -0500 Message-ID: <45117624.8010404@sbcglobal.net> References: <450FE24A.30906@my.home> <450FEFA0.5070800@modsoftsys.com> <45100BB0.2020905@my.home> <45101F74.9050107@sbcglobal.net> <45103310.2040507@my.home> <45104207.1070603@my.home> <4511104F.1090207@my.home> <45116A88.2020909@sbcglobal.net> <45117479.7040809@my.home> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <45117479.7040809@my.home> Sender: linux-msdos-owner@vger.kernel.org List-Id: Content-Type: text/plain; charset="us-ascii"; format="flowed" To: dosemu Jan Willem Stumpel wrote: > Mike McCarty wrote: >>GREAT! But, why did it fail in the first place? > > The immediate reason has been pointed out by Bart. A change in the [snip] > One of the "initscripts" is /etc/init.d/mountdevsubfs.sh, which > contains line like > > (version 15, does not break dosemu) > SHM_OPT= > [ "${SHM_SIZE:=$TMPFS_SIZE}" ] && SHM_OPT="-osize=$SHM_SIZE" > domount tmpfs shmfs /dev/shm $SHM_OPT > > ("improved" version 20, breaks dosemu) > SHM_OPT= > [ "${SHM_SIZE:=$TMPFS_SIZE}" ] && SHM_OPT=",size=$SHM_SIZE" > domount tmpfs shmfs /dev/shm -onoexec,nosuid,nodev$SHM_OPT Ah, I see. Very clear. > This must have been done for security reasons, although I have no > clue about (the severity of) the security issues which are at > stake here. [snip] Hmm. Self-modifying code permitting one to insert code into a shared memory region and execute it? Difficult to catch with a "scanner" I suppose. Thanks for the response. Mike -- p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);} This message made from 100% recycled bits. You have found the bank of Larn. I can explain it for you, but I can't understand it for you. I speak only for myself, and I am unanimous in that!