🚀 go-pugleaf

>>  Years ago, an article
>> appeared - in Software Practice and Experience, I believe - which described
>> a game of some sort, with a master list of high scores.  A challenge was
>> given:  Maintain such a master list, given the constraints that (a) anyone
>> who runs the game program can have their score recorded; (b) no one can spoof
>> the records by accessing the master list directly; (c) any user, without
>> special privileges, can create a new master list for his version of the game.
>> These constraints are easy to satisfy on Unix with a SUID program.  To this
>> day, they are quite difficult to satisfy on most other systems.  (Often, they
>> simply CANNOT be satisfied.)

Huh? Those constraints were easy to satisfy on TOPS-10 by the end of
1976. You could (this was in version 6.04, I believe) specify for each
directory a map from (filename, program, PPN) to permissions,
including append-to-file. Of course, you could also specify 'any' for
any of the three fields when building the map.

Likewise, VMS and MVS (w/ RACKF) both support access lists. I've been
led to believe that AOS also has them.

Obviously, almost anything that you can be done with SUID programs can
be done with access lists. Likewise, I've convinced myself that
anything you can do with access lists can be done with SUID programs.
It's just that the SUID programs are so damn CLUMSY about so much of
it, requiring a new program to be created for each element in the
access list. And of course, you can't set things up so that normal
tools can be used, and still have a reasonably secure system. Whereas
with access lists, you could do:

	program=vi,emacs; user=*; file=jargon.file; perm=rw

to let anyone edit jargon.file with vi or emacs. Anyone want to do the
equivalent with SUID bits?

	<mike