update a running busybox

[Rich Felker]

On Wed, Mar 30, 2011 at 11:51:37AM -0700, Cathey, Jim wrote:
> In this (DNIX) system the file was not 'open' at the user level,
> and as a resident of swap space it didn't really have a device or
> an inode.  (As data/bss segments did not.  Just memory pages backed
> to a blocking store.)  Even if it were required to have dev/inode,
> perhaps to support /proc/X/exe, why could it not get a new assignment
> on the swap device? (Essentially automating what we all have to do
> by hand now.)

I agree, this system is probably conformant as long as the behavior is
limited to files whose only references are system-created maps for
program images and not file descriptors or application-created maps.
Of course you lose some generality and add some complexity to your
system if you have to distinguish these, so I'm not surprised Linux
doesn't do it.

A better approach in my mind would be to move the orphaned inodes to
an invisible directory whose contents are automatically deleted at the
next mount (by the mount utility or the kernel). The kernel could also
wipe them when the last reference is closed, but only if the device is
mounted for write still.

> What ongoing security check would be required for an already-executing
> process?

I'm not saying there's a lot of usage potential in this particular
case, just that the general semantics for deleted open files are
important to security, usually for locking and race-condition-related
purposes.

Rich