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 _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
