Programs that don't work under Plash

rm -r:
needs to open directory FDs and use fchdir() to work without being
vulnerable to symlink races.  fchdir() isn't implemented.

uses fchdir() too, it seems.

tries 1000 times to open files in /tmp in a loop (so hangs for a while),
then aborts (without a descriptive error)
-- really, it should test for EEXIST

/usr/bin/mkisofs: Operation not permitted. Panic cannot set back efective uid.
It does the following:
setreuid32(0xffffffff, 0x1f6)           = -1 EPERM (Operation not permitted)
where 0x1f6 = 502 (mrs), the UID it believes it already has

setresuid32(0xffffffff, 0x1f6, 0xffffffff) = -1 EPERM (Operation not permitted)
(but this doesn't happen with Debian, even though make is 3.79.1 on both)

masqmail is setuid root, and it tries to close all file descriptors,
and consequently cuts off its access to the server.

  X-plash$ emacs
  emacs: Memory exhausted--use M-x save-some-buffers RET
I'm not sure why this is happening.
Emacs doesn't like being run like this, from Bash:
  /lib/ /usr/bin/emacs
This error is mentioned in:

Running the shell "shell" gives:
  sendmsg: Bad file descriptor
  recvmsg: Bad file descriptor
  [2622] cap-protocol: [fd 5] to-server: connection error, errno 9 (Bad file descriptor)
  Can't exec program /bin/sh
  Process shell exited abnormally with code 1
It would appear that XEmacs is closing the file descriptor that Plash uses.

xemacs: also relies on pseudo-terminals; do this:
nm /usr/bin/xemacs | egrep 'getpt|grantpt|unlockpt|ptsname|openpty|forkpty'

Filename completion doesn't seem to work on fabricated directories,
only real directories.  Is it relying on the object type being included
in directory listings?


Now works:

(uses open() on directories)