wcs@hou2b.UUCP (06/03/83)
Jay Lepreau points out that several programs under 4.1BSD create their lock files in /usr/spool/mail. This implies that the directory be writable, and hence I have a problem: I am running a fairly old copy of 4.1BSD, so maybe this has been fixed. When I send mail to "joe", and he doesn't have a /usr/spool/mail/joe file, it is created with MY userid and umask permissions. Thus, even if joe can read his mailfile, he probably can't write to it, and neither can anyone but myself. The main time this problem occurred was when joe read, and deleted, all his mail, and Mail deleted the mailfile for him. I had solved this by setting /usr/spool/mail to dr-xr-xr-x owned by root, and creating mailfiles for all my users with the appropriate ownership and permissions. This allowed them to modify, but not delete, their files, and it seemed to work fine. Do I now have to change this to allow lock files to be created, and has this problem been fixed already? Thanks; Bill Stewart BTL-HO x0705 hou2b!hoscf!bin or hou2b!hoscf!bill
lepreau@utah-cs.UUCP (06/03/83)
Sounds to me that you don't have /bin/mail setuid to root. It must be in order to set the proper ownership and modes on the target file.
pn@amd70.UUCP (06/03/83)
I had the same problem with a non-existent mbox being created with the SENDER as the owner. It turns out there is a variable called "keep" which can be set in the /usr/lib/Mail.rc file which "causes Mail to truncate your system mailbox instead of deleting it when it is empty". If you do this and fix up everyone's mbox, the problem probably won't reoccur very often. At UCB, they tend to be very permissive about things (most mail is readable by all) so I'm not surprised if security seems to be poorly thought out or poorly documented. The "keep" variable IS described in the 2.10 Mail manual, which I can send to interested people. (I have Mail version 2.17, but the manual is only at 2.10.) Phil
shp@decvax.UUCP (06/06/83)
About the problem with the mail file being created with "owner" not being the person receiving the mail. Check the permissions on /etc/delivermail. It should be setuid program. - sam praul decvax!shp
swatt@ittvax.UUCP (06/07/83)
Sam Praul is mistaken (sorry, Sam) about which program in the mail system should be SUID to root: + DO NOT make /etc/delivermail SUID to root. There is code in delivermail to do "setuid(getuid())" at various places, but I have never seen a claim that it is really secure. The successor "sendmail" is supposed to be secure. + DO make /bin/mail SUID to root. This is usually a slightly smarter version of the standard v7 mail. + DO NOT make "rmail" a simple link to "/bin/mail" for UUCP; use the special "rmail" program that comes with delivermail. This one disallows "!" shell escapes. Delivermail uses a separate mailer program for each type of delivery: local, UUCP network, Arpa network, and so on. It "cheats" and uses "/bin/mail" for both local delivery and UUCP delivery. Thus local mail is passed from "ucbmail" (If you run it) to "delivermail" and finally to "/bin/mail" for actual delivery. Only the last stage needs to be able to manipulate files in the mail spool area. There is a bug in the standard 4.1bsd distribution (I don't know what tape range) such that a number of programs which should have been SUID were not. There was an update notice which explained this. The real fix is: su root cd /usr/src/cmd setenv DESTDIR / ; MAKE MODES (csh ["root" runs csh by default]) or: DESTDIR=/ MAKE MODES (bourne shell) This will set the owner and modes correctly for a number of programs. Setting the "DESTDIR" variable is important, or MAKE will try to diddle things in "/4bsd/...". MAKE is a shell script if you're curious. In general, if you have questions about what belongs where and in what mode and owned by whom, this is a good place to start. If you have this problem, you should look at the 4.1bsd bug news reports which come with the standard distribution; you might have missed others. Some of these fixes are quite important and should be made. One of the "UNIX Newsletter" rags (I forget which one), first came out with the mis-information about delivermail. In general, the new publications I've seen promote professional writing and production at the expense of technical accuracy. If you're getting technical advice from various industry rags, make sure the article is signed by someone claiming expertise; professional writers who summarize what they've been told are prone to errors that could prove dangerous. The above obviouly applies to advice you get from the net ... - Alan S. Watt