[ On Sun, May 24, 1998 at 16:13:06 (-0700), Jason Thorpe wrote: ]
> Subject: Re: a.out dynamic libraries 
>
> I could go for a special flag to mmap(2)...

and then....

[ On Sun, May 24, 1998 at 20:29:46 (-0400), der Mouse wrote: ]
> Subject: Re: a.out dynamic libraries
>
> I'd much rather have a flag bit to mmap(2) which considers the mapped
> section as a text segment for VTEXT purposes.  This has the advantage
> that (almost?) all of the necessary underlying machinery is already in
> place for "real" text segments.  It also associates the bit with the
> right thing - the memory segment - letting the underlying file get
> VTEXT set and cleared normally.

I thought of doing this through mmap(2) already, and I think I'm already
ahead of you here, although....
 
[ der Mouse contined: ]
>
> The major disadvantage, I think, is that it means that any file you can
> read you can ETXTBUSY out by mmapping it with this bit set.  On most
> systems that includes interesting things like logfiles - which could be
> very useful to an attacker.

This is exactly the issue I was trying to avoid in my proposal.

On the other hand, maybe it's good to always make a file busy when it's
mmap()ed.  Not being an avid user of mmap(2) I've not thought too hard
about what does or should happen when an mmap()ed file is deleted.  My
initial off-the-cuff-thinking-in-unix-mode response would be that it
should be just as if the file were open when its last link is removed --
the data remains allocated on disk until it all open fds are closed and
unmapped, at which time the inode and disk blocks are relinquished.  In
the mean time the inode will be removed from the last directory it was
referenced in.

Then again I suppose if this were an optional flag to mmap(2) one could
also restrict this feature to root in order to prevent any highjackers
from busying out any readable file(s).

However when I first worked through this issue I decided that it would
be good to keep separate flags to indicate a file locked by the kernel
for text paging and a file locked because it's in use as a shared
library.

Now that I'm re-thinking all of this I've realized that there would be
no need to add any new system call features if we had mandatory file
locking.  Then it would be a simple matter for ld.so to lock shared
libraries against writing (and open(O_TRUNC)).

Speaking of mandatory file locking, I'd prefer the style where one sets
a mode bit on the file in order to make flock()/fcntl() locks into
mandatory locks.  The only other sane option might be to define an
entirely new API for mandatory locks (and do it *right* this time!  ;-)

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>