Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 31 May 1998 21:02:09 +0000 (GMT)
From:      Terry Lambert <tlambert@primenet.com>
To:        dg@root.com
Cc:        tlambert@primenet.com, abial@nask.pl, freebsd-hackers@FreeBSD.ORG
Subject:   Re: Signed executables, safe delete etc.
Message-ID:  <199805312102.OAA13496@usr06.primenet.com>
In-Reply-To: <199805311222.FAA07750@implode.root.com> from "David Greenman" at May 31, 98 05:22:28 am

next in thread | previous in thread | raw e-mail | index | archive | help
>    Terry, sometimes I think we exist in different realities. First of all,
> any user can set a file as executable in VMS. It does not require any special
> privileges.

This has not been my experience, working on compilers on VMS.

> Second, there is no "SYSPRIV" privilege. There is a "SYSPRV"
> privilege, however, that allows the holder access system resources as if
> he had a system UIC. One does not have to have a system UIC to change
> file permissions (including the executable flag); all one needs is to be
> the owner of the file - just like it is in Unix.

Thank you for the spelling correction.

I don't know, off the top of my head, the exact priviledge.  I do know
that when I wrote my own linker, it was required that I install it as
an install image in order to be able to set the executable bit,

At one time, I wrote a bacterium for UNIX and tried to port it to
VMS, but was unsuccessful because of the inability to set the program
as executable (which is distinct from setting the execution bit
which is manipulable by the user, at least prior to VMS 5.3; I can't
speak for later versions, since I didn't have access to VMS source code
after that).


> Third, LISP works just fine in VMS, including dynamic compilation and
> process extension.

You are confusing the LISP example, which I gave as an example of
why requiring priviledges to set something executable was a bad idea,
and the VMS and UNIX LISP extension formats.

For many UNIX LISPs, "precompiled" packages are added into the
executable file after the data known to the header.  A number of
UNIX FORTH interpreters do the same thing.

Back in the 386BSD 0.1+patchkit days, a change was made to the loader
to allow image size to not match the size in the a.out header,
specifically because it broke a number of LISP interpreters (Franz
LISP was the main one I remember).  So 386BSD had a similar "protection"
in it, though anyone could build a linker, unlike VMS.


VMS LISP has no problem with dynamic compilation or process extension,
but unlike UNIX, it does not implement it by extending the data space
and not marking the data space extended in the image header.


					Terry Lambert
					terry@lambert.org
---
Any opinions in this posting are my own and not those of my present
or previous employers.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199805312102.OAA13496>