[prev in list] [next in list] [prev in thread] [next in thread] 

List:       busybox
Subject:    RE: update a running busybox
From:       "Cathey, Jim" <jcathey () ciena ! com>
Date:       2011-03-30 19:15:24
Message-ID: F4AC465B29B61A4FA792A4E6FEA8A202016D3A87 () wamxm01 ! ciena ! com
[Download RAW message or body]

>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.

Can't unmount a device with processes executing off of it.
I believe DNIX could.

>the general semantics for deleted open files are important to security

DNIX did this, not on a file being deleted necessarily, but also on it
being opened for write.  And it _only_ did this for executing images,
anything being used as a regular file continued to behave as before.
Basically it noted whenever it could no longer rely on the original
executable file to feed the in-memory execution cache, and arranged
to move the contents to a private place that it _could_ rely on,
releasing the original reference.  It worked pretty slick.  Want
to get a new program?  Cp or tar it, no special precautions.  Want
to force a resident program to start using the new version?
Then restart it.

-- Jim

_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
[prev in list] [next in list] [prev in thread] [next in thread]