jcp (07/25/82)
An interesting question: Should users be able to 'chown' their files? PWB allows this, V7 and 4.1BSD don't, System III does (I think) Personally I think its a good idea, unless of course you use a disk quota managment facility at your site. No security violations can come about as a result of this, (the user can't of course get his files back once he 'chowns' them). Having just done a PWB conversion, I may be biased, but I can't find any good reasons for not allowing it. -Joe Pistritto-
dan@Bbn-Unix@sri-unix (08/21/82)
From: Dan Franklin <dan@Bbn-Unix> Date: 10 Aug 1982 23:27:56 EDT (Tuesday) Needless to say, chown must then be sure to turn off the setuid and setgid bits.... The only other security violation I am aware of is via the at program, which looks at the user and group names on its files to decide who the processes should be run as. Anyone can put a file in /usr/spool/at to be executed (or chown a file of their own that they've put there). A solution would be to change at to require that the setuid and setgid bits be set on the files it runs.
Wegeng.WBST@Parc-Maxc@sri-unix (08/21/82)
Date: 11 Aug 1982 08:44 EDT "Should users be able to 'chown' their files?" No. What about a program which checks the ownership of a shell command file, and then runs setuid to the owner? This is how at least one version of 'at' works. A user could easily create a root shell if he/she were allowed to chown the command file in /usr/spool/at. I know of at least one site which has had this happen. DW
decot@Mitre@sri-unix (08/21/82)
From: Dave Decot <decot@Mitre> Date: 11 Aug 1982 9:27:40 EDT (Wednesday) Perhaps users should be able to change the ownership of their own files, but some security violations ARE possible unless certain restrictions are placed on the files `chowned'. There are also situations where this facility should not be present at all. Requests to chown files with the 'set-uid' or 'set-gid' bits set should not be honored, or if they are, these bits must be cleared by the chown program. Otherwise, any user might create a shell file or other p|er. Buthat does 'bad' things, set these bits, chown the file to root and have his way. The ability to change the ownership of a directory must also be carefully restricted to avoid any number of unpleasant situations. For example, consider this sequence: % cd % mkdir mutter % cd mutter % cat >foofile asdfjkl asdfjkl ^D % chown her foofile % cd .. % chown her mutter If the user performing this sequence has no write permission on mutter, he has (perhaps unwittingly?) created in his tree a directory he cannot remove. Finally, this mechanism should be severely restricted or not available on systems where disk space is at a premium and users are accounted for the number of blocks they use. A dastardly user might create hundreds of files owned by a user who doesn't know they exist (and may have no way of finding out that they do!). -Dave Decot
gwyn@Brl@sri-unix (08/21/82)
From: Doug Gwyn <gwyn@Brl> Date: 11 Aug 82 16:11:21-EDT (Wed) Yes, System III does allow a user to give away his files. Incidentally, this is trivial to implement on an older UNIX, so long as you remember to turn off the set-UID/set-GID bits! The main arguments pro and con that I can think of are: PRO: The idea that an owner can do what he wants with his property. Convenience in giving someone a copy of something (somewhat mitigated by having to put the copy in a mutually-accessible directory). Spooling daemons and the like can sometimes hand files to their intended owners without having to run set-UID root, so there are fewer security-critical programs on the system. CON: A user can "give" a huge file to another user for the duration of file accounting (say, overnight), then copy it again and delete the old version (presumably still in his private directory) when he needs the file. This could ruin any file accounting by ownership*size (System III accounting works this way). This latter trick could be partially fixed by having chown() apply an automatic umask of 077 to the file being chown'ed. This would still let users maliciously put huge files under somebody else's name, but at least they couldn't get them back without the victim's assistance.
dave (08/27/82)
needless to say, sites that have accounting for resources should also not permit general chown...
DEAN@Usc-Ecl@sri-unix (08/28/82)
From: Jeff Dean <DEAN@Usc-Ecl> Date: 22 Aug 1982 2143-PDT I agree there is a potential security problem with "at" when users are allowed to "chown" their own files. I disagree with your solution. The problem here is with "at", and not with "chown". If I "chown" one of my files to root, THAT is not a security problem. If there is a command that does a setuid on an arbitrary program and then executes that program, without adequately checking to make sure that the setuid is OK, then that command is the one directly responsible for the security lapse. Please don't restrict users unnecessarily by disallowing chown. Instead, fix the programs that are directly responsible for the security problems. -- Jeff -------
FC01@Usc-Ecl@sri-unix (09/02/82)
From: FC01 <FC01@Usc-Ecl> Date: 28 Aug 1982 1511-PDT I hate to start up the old newline discussion again, but it seems as if every computer except the data general machines expect end of lines to be entered with a <cr>. This being the case, it seems silly to use <lf> as the newline character, think of the added compatability of being able to type in what gets typed out, and having the computer type out what should be typed in! For file transfer, everyone has to substitute <cr> for <lf> and then the other side has to send back <lf> for <cr> and the sender has to see the <lf> a the <cr> it sent for the <lf> it had in the first place. If they were all <cr> it would be much easier, more sensable, etc. Perhaps only the stdio source defining /n has to be changed (to char code 15 from 12) and everybodies programs will all work again with only a recompilation! Oh, you man people use numbers for this stuff in programs? What a shame! Fred -------