Shap writes:
> > An issue I didn't see raised, probably because it is not
> > relevant to the design as given, is "execute only" access...
>
> There isn't really a difference between execute only and read only from a
> security perspective -- both constitute reads by the CPU. Preventing a user
> from examining your code can be done by interposing a process boundary, though
> execute only probably does have advantages in reducing certain classes of
> programming errors.
It may well be that execute-only and read-only are indistinguishable in EROS, but they are certainly quite distinct in a filesystem-based OS like VMS or Unix.
The usual case it is useful is when the executable contains some kind of secret -- a database password, for instance. While it is true that both executing the executable and reading the executable are "reads", executing the executable is done by reads under the control of the *executable itself*, while reading the executable is done by reads under the control of some other process.
> The real reason, however, is rather more prosaic: most hardware no longer
> supports execute-only permissions. Most OS's no longer support it actively.
Hardware support is relatively irrelevant. Indeed, a program compiled normally with Unix compilers includes initialized static variables in its executable image; such a program could not run if it couldn't read parts of the memory-mapped executable.
As long as only processes spawned *from* a particular executable could *read* the executable, and that executable was designed not to spill its guts on command, and without the various ptrace/LD_PRELOAD/#!-race/#!-read/etc holes that make Unix --x permissions ineffective, and without some of the problems of networked filesystems, execute-only is easy to do without hardware support.
-- <kragen@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/> TurboLinux is outselling NT in Japan's retail software market 10 to 1, so I hear. -- http://www.performancecomputing.com/opinions/unixriot/981218.shtml