mwm@OPAL.BERKELEY.EDU (Mike Meyer, I'll be mellow when I'm dead) (10/04/86)
>> 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