cannot map temp file pool

I did 'nothing' (apart from the usual Debian dist-upgrades) to my beautifully-working dosemu installation and now I get this.. sigh..

 jws@vega:~$ xdosemu

You do not have the DOSEMU vga font installed and are running remote X. You need to install the vga font on your _local_ Xserver.
Look at the readme for details. For now we start with an fixed font, which does not display all national characters correctly. ... be warned

ERROR: MAPPING: cannot map temp file pool, Operation not permitted
ERROR: MAPPING: cannot map temp file pool, Operation not permitted
Segmentation fault
jws@vega:~$

WTH is this? No idea what "map temp file pool" means. I hope someone is still around who can answer this. The dosemu font was always OK, BTW.

Regards, Jan

[resent with list included]
Jan Willem Stumpel -- 19.09.2006 15:27 --:

I'd run xdosemu under strace and look for "permission denied" errors there.

dam

Damyan Ivanov                           Modular Software Systems
[email protected]
phone +359(2)928-2611, 929-3993              fax +359(2)920-0994
mobile +359(88)856-6067             [email protected]/Gaim

I tried that -- but could not make sense of it. I get things like

open("/dev/shm/dosemu_16975", O_RDWR|O_CREAT|O_TRUNC|O_NOFOLLOW, 0600) = 5

fcntl64(5, F_GETFD)                     = 0
fcntl64(5, F_SETFD, FD_CLOEXEC)         = 0
unlink("/dev/shm/dosemu_16975")         = 0
ftruncate(5, 0)                         = 0
ftruncate(5, 15794176)                  = 0

mmap2(NULL, 15794176, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, 5, 0) = -1 EPERM (Operation not permitted)
write(4, "ERROR: MAPPING: cannot map temp "..., 67) = 67 write(2, "ERROR: MAPPING: cannot map temp "..., 67) = 67

15794176 is some suspiciously "round" number (hex 00F10000).

I'd appreciate any ideas.

Regards, Jan

The man page for mmap suggests that you get EPERM when you ask for PROT_EXEC but tmpfs was mounted no-exec. You should check the mount options for tmpfs, I think.

Cheers,
Rob Komar

These things make some sense to me. Perhaps I can help. Someone with the source can help better.

open(.,.,.) opens files or devices for reading or writing, and returns a small positive integer on success. This integer is used for later calls to do things to the file or device. If it fails, it returns -1. This indicates successful open on /dev/shm/dosemu_16975 with READ+WRITE, CREATE if non-existent, TRUNCATE an existing file and reuse it, do NOT FOLLOW links.

Now, /dev/shm is SHARED MEMORY. It is there to allow multiple processes to access the same memory area without having to use interprocess communication. There is no file involved.

The open channel number (FD or File Descriptor) is 5.

fcntl(fd,option,...) does various File CoNTroL operations. It returns 0 for success, -1 for an error. FD number 5 (return from above open) was successfully queried.

F_GETFD
Read the close-on-exec flag. If the FD_CLOEXEC bit is 0, the file will remain open across exec, otherwise it will be closed.

Again, FD 5 has had an option set successfully.

F_SETFD
Set the close-on-exec flag to the value specified by the FD_CLOEXEC bit of arg.

In this case, set to TRUE.

The "file" has been "removed". This means it has been marked by the system for removal. But it is still open (we guess, since no close() has been done), so the "file" still exists, but when it is closed, it will automagically go away.

IOW, when all processes have relinquished access to the shared memory (like by exiting to the system), then the shared memory will be returned to the pool.

ftruncate(Fd,Size) sets the size of a file. I suppose that in the case of shared memory, it resizes it. This is a successful call.

Ditto. It successfully changed FD 5 to 15794176 bytes.

This is a POSIX call, IIRC.

This call has failed. mmap2() attempts to map a shared memory region to a real process relative memory address so it can do accesses.

void * mmap2(void *start, size_t length, int prot, int flags, int fd,
off_t pgoffset);

start the requested start location in memory; this is only a
suggestion, and the system may not use the requested address. NULL means you are willing to accept whatever the system gives you (which is what is going to happen, anyway)

length number of bytes to map to the process memory

prot access protection requested

flags some access flags

fd File Descriptor (5 in this case, our shared memory region)

pg_offset offset into the shared memory region to start
mapping. In this case, no beginning piece is skipped over, we want it all.

This call, when it succeeds, returns a pointer to the shared memory region. Again, this was done on FD 5. The requested permissions are READ, WRITE, EXECUTE, flags are SHARED access. The return indicates that the operation failed (-1) and the errno indicates PERMISSION DENIED.

So, it appears that something is wrong with your permissions on /dev/shm/dosemu_16975.

$ ls -ld /dev/shm
drwxrwxrwt  2 root root 40 Sep  8 06:57 /dev/shm

My shared memory is accessible to everyone, apparently.

I wonder whether your permission bits are incorrect on /dev/shm.

This is a successful attempt to write some byes to FD 4 (probably some log file). It tried to write 67 bytes, and wrote 67 bytes. This is a successful call, probably reporting the mmmap2() failure.

This is a successful attempt to write to FD 2 (stderr, the standard error reporting file, likely your display) probably the very same message.

It's the length of the mapped area. It's normal for this to be a "round" number.

Well, hopefully I've given you some.

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!

Well, in the first place, sincere thanks for your reply (and also thanks to the others who replied, whose messages I still have to digest). It seems that while development of dosemu has stopped, the list is still very much alive.

But..

 jws@vega:~$ ls -ld /dev/shm
 drwxrwxrwt 3 root root 60 2006-09-19 17:24 /dev/shm

The permissions seem the same.

Regards, Jan

It's not just the permissions that are important, but whether you can directly execute files within the temporary filesystem. Run 'mount' and see if tmpfs is mounted with the 'noexec' option. If it is, then that's at least one of your problems.

Cheers,
Rob Komar

Aha..

vega:/home/jws# mount
/dev/hda5 on / type ext2 (rw,errors=remount-ro)
proc on /proc type proc (rw,noexec,nosuid,nodev)
/sys on /sys type sysfs (rw,noexec,nosuid,nodev)
devshm on /dev/shm type tmpfs (rw)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
usbfs on /proc/bus/usb type usbfs (rw,noexec,nosuid,nodev)
/dev/hda6 on /dosd type vfat (rw,noexec,nosuid,nodev,umask=000)
automount(pid2284) on /misc type autofs
(rw,fd=4,pgrp=2284,minproto=2,maxproto=4)
rpc_pipefs on /var/lib/nfs/rpc_pipefs type rpc_pipefs (rw)
binfmt_misc on /proc/sys/fs/binfmt_misc type binfmt_misc (rw)
vega:/home/jws#

There doesn't seem to be a filesystem actually called tmpfs but there is devshm which has the "type" tmpfs.

Is this a clue? Maybe I should make some link. I wonder what tricks were performed by my latest Debian dist-upgrade.

For completeness, here is /etc/fstab:

# /etc/fstab: static file system information.
#
# <file system><mount point><type><options> <dump><pass>

/dev/hda5      /        ext2  defaults,errors=remount-ro  0 1
/dev/hda6      /dosd    vfat  defaults,rw,user,umask=000  0 0
/dev/hda7      none     swap  sw                          0 0
proc           /proc    proc  defaults                    0 0
/dev/fd0       /floppy  auto  defaults,user,noauto        0 0
/dev/hdc       /cdrom   iso9660 defaults,ro,user,noauto   0 0
/dev/hdd       /cdrw    iso9660 defaults,user,noauto      0 0
procyon:/      /nfs     nfs   defaults,noauto,rw          0 0

vega:/home/jws#

There is no tmpfs, but there never was, and dosemu always worked (until today).

Regards, Jan

Hi Jan Willem,

it's an issue with the 'initscripts' Debian package, in /etc/init.d/mountdevsubfs.sh

Hopefully it's only temporary: it also breaks UML
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=386945

The DOSEMU source code could probably work around it by mmap()ing READ|WRITE and then mprotect it with EXEC. But maybe at some future point someone will restrict mprotect() to report EPERM in such situations too for security reasons.

Anyway. another way to work around it is to change $_mapping. If you set it to "mapashm" or "mapfile" then dosemu should work again.

Bart

I don't understand why SHARED MEMORY needs execution access, anyway.

This looks like a defect in the code to me.

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!

DOSEMU needs shared memory for things like the HMA and EMS that are mapped multiple times. E.g. the 64K at 1MB must be able to wrap and so point to the same address as 0. The only way to accomplish that in Linux is too use either shared memory or a temporary file (slower).

DOS programs execute in this memory, so the memory needs to be executable.

Bart

Thanks a lot. This worked.

Regards, Jan

GREAT! But, why did it fail in the first place?

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!

The immediate reason has been pointed out by Bart. A change in the Debian initscripts package. The latest version in which dosemu worked by default is initscripts_2.86.ds1-15_i386.deb. Last Saturday, this was replaced by initscripts_2.86.ds1-20_i386.deb. So the breakage seems to be Debian-specific (for now).

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

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.

I do not know why the Debian maintainer of dosemu himself did not tweak to this breakage. Or maybe he did, and the Debian version of dosemu now has a different $_mapping default. Haven't checked this yet. Though a Debian user, I've been compiling my own dosemu from source for years, not liking Debian's dosemu package (see my "dosemu for dummies" page).

Regards, Jan

[snip]

Ah, I see. Very clear.

[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!

Hi!

Am Mittwoch, 20. September 2006 19:03 schrieb Jan Willem Stumpel:

I have surged the new Debian maintainer to update the Debian dosemu package. It is still 1.2.1 and I am afraid it will stay like this because the current maintainer has not done a bit. I suspect that the current maintainer has not even used dosemu himself. So if you want to use a current dosemu in Debian, you have to compile it yourself. :(

Regards

Claudia

Actually, in Debian Sid (unstable), it is now 1.2.2.

But this was introduced only last June, and it has the default $_mapping = "". So it is guaranteed not to work on a updated Debian Sid system.

Something must be wrong in the communication (two-way) between Debian and dosemu..

It would be a pity if dosemu would die, either by the present conflict among the developers, or by neglect by the major distributions. There are many legacy DOS programs out there which are still actively used. I get between 100 and 200 non-robot hits every week on my dosemu page alone. There is still interest in this project "out there".

Regards, Jan

Am Donnerstag, 21. September 2006 13:17 schrieben Sie:

Agreed!!

Regards

Claudia

Jan Willem Stumpel escreveu:

Well, this is very common in Linux programs. It works... so if someone needs something *more* then it's a different story :)

Alain