Linus Torvalds <torvalds@transmeta.com> writes:


> I think it literally was /var/run/[uw]tmp, and using MAP_DENYWRITE to
> disable all logins.
> 
> But it pretty much covers _any_ logfiles that are readable (and thus
> openable) by users.

Thank you for the help understanding the historical pitfalls.


> > Currently checking to see if the file is executable looks good
> > enough.
> 
> [ executable by the user in question, not just anybody ]
> 
> Yes, I suspect it is.

If it isn't we can add an extra check to make certain no one has
write permission to the file.  But that feels icky.

Looking at the problem a little more you can do better than MAP_DENYWRITE.
Instead of dening write access per mapping we can more easily deny
write access from the open of a file.  And add an O_EXEC option to open.

Adding the O_EXEC is possible now because we keep a struct file in the 
vm_area_struct.  Which was not the case when MAP_DENYWRITE was
written.  This allows the mapping code to totally ignore the read only
mapping case.

What follows is my initial patch to implement O_EXEC against 2.4.12.
With this patch I totally delete MAP_DENYWRITE except in the arch
headers so we don't accidently reuse it's value. open_exec becomes
open_filp(O_EXEC | O_RDONLY).  And now we don't have to manually
call allow_write_access whenever we call fput on a mapping.  

My big question is how to correctly define O_EXEC for every
architecture.  But I would like to know if there are objectionable
parts as well.

Eric