On Tue, Oct 30, 2001 at 06:45:36AM -0800, Jason R Thorpe wrote:
> On Tue, Oct 30, 2001 at 11:04:34AM +0000, Ben Harris wrote:
> 
>  > In article <20011029215305.A11913@spathi.chuq.com> you write:
>  > >but I really don't think we should allow unpriviledged users
>  > >to cause any file they can read to become read-only just by
>  > >mapping it with PROT_EXEC.  the VTEXT flag was originally used
>  > >just for the read-only part, I was overloading it when I used it
>  > >for affecting paging behaviour.
>  > 
>  > Hmm.  What's the reasoning behind protecting executables against being
>  > overwritten, and why doesn't it apply to shared libraries as well?
> 
> Yah, I'm a little fuzzy on this, too.  If the idea is that you don't
> want the underlying file changing while you deamand-page from it, then
> that applies to shared libraries, too.

you'd like this to apply to shared libraries, but not to, say, /etc/passwd.
both of these can be mapped with PROT_EXEC by anyone, since both can be
opened for reading, which is all we have ever required.  I sorta recall
someone suggesting before we restrict PROT_EXEC mappings to files that are
executable, but I don't think that's a good idea since we've always
allowed shared libs to be non-executable.  it seems to me that that
the "executable" bit has come to mean "execve()able" for netbsd,
and it would be really nasty to change that now.

another way to get the same effect as making the file read-only would be
trigger coping of any copy-on-write PROT_EXEC mappings before processing
writes to files with any PROT_EXEC mappings.  this would take care of
anything that was really using the file as a shared library, since the
runtime linker creates all its mappings as copy-on-write.  implementing
this seems pretty annoying though.  maybe we can up with some other idea
that would also make shared libraries happy but that would be less
complicated.

it also occured to me that neither this scheme nor the current scheme work
if the shared library or executable is being accessed through a layered
filesystem.  the VTEXT flag is set on the layered vnode instead of the
underlying vnode.  and NFS can't prevent the file from being modified from
other nodes, so it kills the process instead of it notices a VTEXT file
has been modified.  this whole business is somewhat hit-and-miss already.

-Chuck