Perhaps we can have a pair of syscalls to get/set the dumpable flag for
the current process. If the process knows what it is doing, it could
set its own dumpable flag. Problem: it's Linux-specific, but so is our
/proc...
A syscall to get the dumpable flag could be useful too - for example,
to make sure ld.so ignores LD_xxx not only for set[ug]id programs, but
also for unreadable ones (otherwise they aren't really unreadable (any
user can trick them into executing arbitrary code, which can dump the
process address space to a file) - it could be a security problem if
there are things like encryption keys compiled in unreadable binaries
- there is at least one package which does this: deslogin).
Or maybe we should start working on a "real" /dev/fd filesystem as
found on Solaris (possibly other systems too, but I can't check right
now). Quoting from Solaris 2.5 fd(4) man page:
These files, conventionally called /dev/fd/0, /dev/fd/1,
/dev/fd/2, and so on, refer to files accessible through file
descriptors. If file descriptor n is open, these two system
calls have the same effect:
fd = open("/dev/fd/n",mode);
fd = dup(n);
On these files creat(2) is equivalent to open, and mode is
ignored. As with dup, subsequent reads or writes on fd fail
unless the original file descriptor allows the operations.
[...]
DIAGNOSTICS
open(2) returns -1 and EBADF if the associated file descrip-
tor is not open.
One nice thing about these files is that they are really character
devices (minor number == fd number), and so they don't need to be
tainted (that was necessary to avoid users logging in to their
own account using ftp, and having access to all the ftpd's file
descriptors. But ftpd allows only access to regular files, not
devices.) - /dev/fd/* files on Solaris are all 0666 root.root).
Now, I have tried looking into implementing a /dev/fd/* driver
(as described by the Solaris man page), but I'm not sure if it
is possible with our current VFS interface. I can have my own
low level open() routine, but I can't replace the existing code
which does all the "struct file" allocation (unnecessary in this
case - we just need the minor number of the device, do a "dup"
and return the new file descriptor). Any ideas? (other than
a dirty hack: add a check for /dev/fd major directly into the
linux/fs/open.c code - but Linus probably wouldn't like it very
much ;-)
> Also, when using "ps" you don't see the real
> name of the process anymore, but eg. "/bin/sh /proc/19445/fd/3" instead.
> To do better would require some kernel support.
If we do the /dev/fd trick in the kernel, we probably can also export
the real script name via procfs...
[Another idea, somewhat unrelated: start moving /proc to a new location,
so that it doesn't conflict with Solaris /proc, if someone ever implements
that for more binary compatibility between SparcLinux and Solaris. For
now mount procfs under /proc-linux (or whatever) and keep a symlink
/proc -> proc-linux for compatibility until all programs are changed to
use /proc-linux; when that is done we can have a Solaris-like /proc.
Choosing the same pathname for something that is quite different from
other systems was a mistake IMHO... Does Digital Unix also have this
/proc filesystem, or is it Solaris-specific?]
Marek