Aucbvax.4541 fa.unix-wizards utzoo!decvax!ucbvax!unix-wizards Mon Oct 19 12:09:29 1981 group id's and UNIX protection >From walton@LL-XN Mon Oct 19 11:22:23 1981 Since the problem of multiple group id's has been raised, I might as well give up my vow of silence on protection issues and share with you some conclusions, most of which I came to years ago, about the UNIX security system. Maybe I might goad the powers at be into implementing something I would actually find usable. In the first place, the UNIX security system is not very good. Problem 1 is that few people want to waste time running newgrp. Problem 2 is that newgrp is not orthogonal to normal program writing: if you write a program that needs files from multiple sources you do not want to call newgrp in the middle of the program- the security system should be invisible to programmers. You get terribly fouled up as soon as different groups start overlapping and want to have common members, or programs that they have a common interest in maintaining, or data they want to share with each other but not the whole world, etc. Problem 3 is that the current process is not a good place to get the group id for a new file. The containing directory is a much better place. Problem 4 is that there is a confusion between accounting, which probably should be a user id function, and security, which probably should be a group id function. Clearly the solution, and the only one as far as I can see, is to have multiple group id's per process with files inheriting their containing directory's gid (and having only one gid). Supergroup should be implemented, superuser abandoned, and user id's become primarily an accounting function. Set group id has to become additive: you add to the list of process group id's temporarily. Set user id can be as currently; it changes who gets charged. Along with each gid in its list of such a process should have a set of permissions, so that it can, say, read with some gid but not write with it. The login uid should should also be one of the gid values so it may retain the security function of protecting files completely private to a single user, like .mail, but will not be removed from the list of effective gid's when the process changes its uid for accounting reasons: that is, the process uid will cease to have ANY security function but the login uid will initially be both the process uid and a process gid. One important principal is to insist that programs should not have to know about the protection system in order for humans to be able to put locks on files and pass out the keys, as it were. Another important principal is that it should be very easy to give any user enough keys so that he never has to bother with the protection system, without giving him keys to the whole world. And I guess the MOST important principal is that protection had better be very automatic, for aside from putting a lock on the very outermost door its hard to justify wasting any manpower at all on it to people who are trying to get work done. I have NO intention of implementing anything. Enjoy! ----------------------------------------------------------------- gopher://quux.org/ conversion by John Goerzen of http://communication.ucsd.edu/A-News/ This Usenet Oldnews Archive article may be copied and distributed freely, provided: 1. There is no money collected for the text(s) of the articles. 2. The following notice remains appended to each copy: The Usenet Oldnews Archive: Compilation Copyright (C) 1981, 1996 Bruce Jones, Henry Spencer, David Wiseman.