wnp@iiasa.AT (wolf paul) (10/31/90)
I would like some comments/advice on the feasibility of having a central mail spool directory for all users on a UNIX LAN, which would be cross-mounted to all machines. I have users who log in on different machines at different times, but expect to be notified by their shell or biff when new mail for them arrives, regardless of where they are logged in. Short of aliasing each user to a list of all machines, which would produce multiple copies of his/her mail, the above seems to be the only solution. However, I would like to know if I should expect problems with processes on different machines accessing the file at the same time. Are the lock file mechanisms based on process ids (in which case they are not guaranteed to be unique if different machines access the file, nor will a "kill -0" produce the right result)? The network has two VAXen running Ultrix 3.0, several VAXstations also running Ultrix 3.0, several SUN SparcStations, and a couple of 386 machines with System V. We use the standard mailers which come with each OS, as well as elm and mh. We are currently using sendmail, but are thinking about switching to smail3. -- Wolf N. Paul, UNIX SysAdmin, IIASA, A - 2361 Laxenburg, Austria, Europe PHONE: +43-2236-71521-465 FAX: +43-2236-71313 UUCP: uunet!iiasa!wnp INTERNET: wnp%iiasa@relay.eu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET
jjb@cs.wayne.edu (Jon J. Brewster) (11/01/90)
We do have a network-wide mail spool here, nfs-mounted on a number of Sun and DEC (Ultrix) hosts. I have seen no problems that could be traced to this arrangement. I modified the sendmail.cf file on all machines except one, the mailhost, to forward mail to the mailhost instead of doing local mail delivery. I suspect this is essential to making things work properly. (I didn't use Sun's OR macro because it produced some unwanted effects in conjunction with mail originating within rn(1).) This scheme works both will a mail spool which physically resides on the mailhost and with one which is nfs-mounted from another server. -- -jjb
haynes@ucscc.UCSC.EDU (99700000) (11/01/90)
One thing you have to consider here is whether security is going to be
a problem. With ordinary NFS any workstation on which the user can
become root allows the user to impersonate any other user and read
the mail.
I guess 'secure NFS' is a way around this. We're planning to use the MIT
Project Athena technology, in which mail is delivered to post-office
machines. The users at workstations access it from there using a
Kerberos-authenticated POP protocol. Another Athena component, Zephyr,
is used for incoming mail notification.
haynes@ucscc.ucsc.edu
haynes@ucscc.bitnet
..ucbvax!ucscc!haynes
"Any clod can have the facts, but having opinions is an Art."
Charles McCabe, San Francisco Chroniclekehoe@scotty.dccs.upenn.edu (Brendan Kehoe) (11/01/90)
In <8368@darkstar.ucsc.edu>, haynes@ucscc.UCSC.EDU.UUCP writes: >I guess 'secure NFS' is a way around this. I was told by someone at Sun that they recommend not using secure NFS because it's too (and I quote) "unpredictable". One example of this unpredictability is if you try to mount the /usr partition via secure NFS on a client .. it'll tell you the portmapper's not responding. (Cuz there's no way for it to actually get the rest of the code cuz of the secure problem.) This was under 4.0.3; I can't say one way or the other about 4.1. (Haven't had the impetus to try it.) Since I'm the only one ever becoming root on the systems on my net, I don't have to worry about people impersonating each other. (Which is probably a luxury.) Brendan Kehoe | Soon: brendan@cs.widener.edu [ Oooooo, by Friday? ] For now: kehoe@scotty.dccs.upenn.edu | Also: brendan.kehoe@cyber.widener.edu "It's a distinctly non-trivial task to decompile a stripped, encrypted binary into something that can be understood." - Keith Bostic, on the Internet worm
bothe@net7.uucp (11/01/90)
we use nfs mounted spool mail dirs with 7 Targon/35 > 1 year.
There were no great bugs, but sometimes the simultaneous on >1 host
written mails (by cron e.g.) were intermixed (locking problem?).
S I E M E N S Richard Bothe, NIXDORF COMPUTER AG, Dep PDT-M 24
------------- Berliner Str. 95, W-8000 Munic (West Germany)
N I X D O R F Tel.: +49 89 3601 2956, USA: bothe.muc@nixdorf.com
(SNI) !USA: bothe.muc@nixdorf.de, NERV: bothe.mucwnp@iiasa.AT (wolf paul) (11/01/90)
In article <8368@darkstar.ucsc.edu> haynes@ucscc.UCSC.EDU.UUCP (Jim Haynes) writes: >One thing you have to consider here is whether security is going to be >a problem. With ordinary NFS any workstation on which the user can >become root allows the user to impersonate any other user and read >the mail. Actually, every implementation of NFS I have seen (Ultrix 3.0, SunOS 4.x, Interactive SysV/386) allows you to limit Root Access to to specific machines on a per-filesystem basis, in /etc/exports. The syntax varies from OS to OS, but the concept is the same. As someone else has suggested, if one modified the sendmail cf files to only do delivery on one machine, then there is no need for root access to the mail spool from any other machine. -- Wolf N. Paul, UNIX SysAdmin, IIASA, A - 2361 Laxenburg, Austria, Europe PHONE: +43-2236-71521-465 FAX: +43-2236-71313 UUCP: uunet!iiasa!wnp INTERNET: wnp%iiasa@relay.eu.net BITNET: tuvie!iiasa!wnp@awiuni01.BITNET
rickg@toshiba.tic.oz (Rick Gunderson) (11/02/90)
In <924@iiasa.UUCP> wnp@iiasa.AT (wolf paul) writes: >I would like some comments/advice on the feasibility of having a >central mail spool directory for all users on a UNIX LAN, which >would be cross-mounted to all machines. >I have users who log in on different machines at different times, >but expect to be notified by their shell or biff when new mail for >them arrives, regardless of where they are logged in. On Sun386i machines running SunOS 4.0.2, $USER can have her/his mail delivered straight to their home directory (/home/$USER/mail/inbox). This means that no matter where $USER logs into, he/she can read their mail because (at least under SunOS) their home directories are always auto-mounted on the host on which they login. The /bin/mail program in SunOS 4.0.2 consults a yellow pages map called ``policies'' that (among other things) determines if mail should be delivered to /home/$USER/mail/inbox to the (usual) /usr/spool/mail/$USER file on the machine that exports the /home/$USER directory (I'll call this machine the ``homehost''). Unfortunately, on non-Sun386i Sun workstations, the /bin/mail program is "dumb" and always delivers to /usr/spool/mail/$USER on the homehost machine (which causes the hassle that you are trying to avoid) :-(. Why Sun didn't supply the Sun386i-style of /bin/mail with their other workstations is anybodies guess. >... We are currently using >sendmail, but are thinking about switching to smail3. One suggestion would be (since you say you are running sendmail) to fix your sendmail.cf file so that _local_ mail deliveries are not handled by /bin/mail but are handled by a program that you write called (say) homemail. The homemail program could then deliver mail sent to $USER in /home/$USER/mail/inbox rather than to the /usr/spool/mail/$USER that /bin/mail always delivers to. Another suggestion would be to simply export the /usr/spool/mail/$USER file so and mount it on every machine that $USER logs in on. Mail delivery would still always be done on the homehost of $USER (via sendmail) and $USER could read his/her mail file on any machine on which it is mounted. Good luck! Rick -- ============================================================================== = Rick Gunderson - Toshiba International Corp. = = ACSnet: rickg@toshiba.tic.oz Internet: rickg@toshiba.tic.oz.au = = Phone: 61-2-428-2077 Fax: 61-2-427-7405 = = Post: Private Bag 29, Lane Cove, NSW, Australia 2066 = ==============================================================================
fpb@ittc.wec.com (Frank P. Bresz) (11/02/90)
FLAME ALERT FLAME ALERT FLAME ALERT FLAME ALERT In article <715@toshiba.tic.oz> rickg@toshiba.tic.oz (Rick Gunderson) writes: >In <924@iiasa.UUCP> wnp@iiasa.AT (wolf paul) writes: >>I would like some comments/advice on the feasibility of having a >>central mail spool directory for all users on a UNIX LAN, which >>would be cross-mounted to all machines. >>I have users who log in on different machines at different times, >>but expect to be notified by their shell or biff when new mail for >>them arrives, regardless of where they are logged in. >On Sun386i machines running SunOS 4.0.2, $USER can have her/his mail delivered >straight to their home directory (/home/$USER/mail/inbox). This means that no >matter where $USER logs into, he/she can read their mail because (at least >under SunOS) their home directories are always auto-mounted on the host on >which they login. Sure so long as they don't have an account that they want to use anywhere but a 386i. >The /bin/mail program in SunOS 4.0.2 consults a yellow pages map called >``policies'' that (among other things) determines if mail should be delivered >to /home/$USER/mail/inbox to the (usual) /usr/spool/mail/$USER file on the >machine that exports the /home/$USER directory (I'll call this machine the >``homehost''). Yes this was when Sun thought YP would save humanity from themselves so they created more maps than they knew what to do with, and the wonderful group who brought you the 386i which just can't seem to make it on it's own without YP (what a MAJOR lose), added even more. Mounting /{var,usr}/spool/mail on Sun's or on other machines has been shown to work fairly well. I used it as far back as Sun 3.X. I just had to be careful about my aliases file. But hey I am a big boy I can handle the trauma of a few mail files showing up in the wrong place owned by 'nobody'. But when the designers of the (wonderful) Sun386i charged off they had no concern at all about what they were doing in respect to the rest of their very own company. The Sun386i has not anywhere near the look and feel of a Sun3/4. It is a brain damaged piece of trash, I wish we didn't own. I have since neutered all of the 386i's under my influence and made them behave themselves by having them NIS (Sun was apparently sued big for using YP a trademark owned by British Telecomm) served by a 4/490 running 4.1_PSR_A. And yes I did HAVE to create this incredibly bogus policies file. But you better believe I set it to spool delivery. (Actually I hacked the aliases files so that everything is always routed the server anyway) This was yet another case of Sun breaking a great many things because (excuse the slur) some grad student thought it would be cool to have mail delivered to your home directory. (I just can't break the fealing that Sun hired a bunch of grad students and said "hey we need an intel prouct please build us one"), Oh by the way ever notice that using finger to tell if someone has read their mail on one of these stupid machines is utterly useless. The finger program was never told about the wonders of YP and the policies MAP. The Sun 386i is a brain damaged piece of dead weight. It is so brain damaged that the default login files produced by that wonderful tool 'SNAP' (blech) have setenv MAIL all through them. No other machine I know requires the MAIL env to be set for things to work properly, but on the 386i you must (hey it's user friendly). >Unfortunately, on non-Sun386i Sun workstations, the /bin/mail program is "dumb" >and always delivers to /usr/spool/mail/$USER on the homehost machine (which >causes the hassle that you are trying to avoid) :-(. >Why Sun didn't supply the Sun386i-style of /bin/mail with their other >workstations is anybodies guess. Because they woke up to the grave error they made after they were thrashed verbally by many users of the brain damaged Sun386i. This machine was a complete and utter disaster from start to finish. :-) Can you guess I just can't stand the Sun386i. But hey Ford built the Edsel. >>... We are currently using >>sendmail, but are thinking about switching to smail3. >One suggestion would be (since you say you are running sendmail) to fix your >sendmail.cf file so that _local_ mail deliveries are not handled by /bin/mail >but are handled by a program that you write called (say) homemail. >The homemail program could then deliver mail sent to $USER in >/home/$USER/mail/inbox rather than to the /usr/spool/mail/$USER that /bin/mail >always delivers to. >Another suggestion would be to simply export the /usr/spool/mail/$USER file >so and mount it on every machine that $USER logs in on. Mail delivery would >still always be done on the homehost of $USER (via sendmail) and $USER could >read his/her mail file on any machine on which it is mounted. Well Sun now uses /var/spool/mail not /usr/spool/mail. Which it marginally supports via the OR switch in sendmail.cf. If you mount /var/spool/mail everything automagically gets routed to the server. But hey watch out if you mount /usr/spool/mail because that's what you're used to it won't route. Why, sendmail looks in the mount tables and if it doesn't see /var/spool/mail it assumes you don't have a mounted mail partition (what a hack) Also this would also result in multiple NFS mounts in an already superbly overmounted world. Instead of just 1 mount of the entire /var/spool/mail from another machine. I think delivering mail anywhere but the spool directory is a big GIANT lose for a great many reasons too numerous to list. I absolute abhore any suggestion to do so. WE NOW RETURN TO YOUR REGULAR COOL HEADED NEWSGROUP. -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | +1 412 733 6749 | My opinions are mine, WEC don't want 'em.
news@usenet.ins.cwru.edu (11/06/90)
Frank Bresz writes: > I think delivering mail anywhere but the spool directory is a big >GIANT lose for a great many reasons too numerous to list. I absolute >abhore any suggestion to do so. List them, please. We have mail delivered to home directories (via a special delivery program I wrote that people run from .forward files) and have found it to be the easiest way to solve the problem in a heterogeneous environment. Chet -- Chet Ramey Network Services Group ``I die, Horatio'' Case Western Reserve University chet@ins.CWRU.Edu
fpb@ittc.wec.com (Frank P. Bresz) (11/06/90)
In article <1990Nov5.213421.6864@usenet.ins.cwru.edu> news@usenet.ins.cwru.edu writes: >Path: ittc!uunet!tut.cis.ohio-state.edu!usenet.ins.cwru.edu!news >References: <924@iiasa.UUCP> <715@toshiba.tic.oz> <FPB.90Nov1222308@ittc.ittc.wec.com> >Reply-To: chet@po.CWRU.Edu >Lines: 18 >Nntp-Posting-Host: thor.ins.cwru.edu >Frank Bresz writes: >> I think delivering mail anywhere but the spool directory is a big >>GIANT lose for a great many reasons too numerous to list. I absolute >>abhore any suggestion to do so. >List them, please. We have mail delivered to home directories (via a >special delivery program I wrote that people run from .forward files) >and have found it to be the easiest way to solve the problem in a >heterogeneous environment. Well lets see a fast scan if man pages and related things lists as items which (on SunOS) specifically reference /var/spool/mail/ : biff (1) - give notice of incoming mail messages bin-mail, binmail (1) - an early program for processing mail messages from (1) - display the sender and date of newly-arrived mail messages old-prmail (1) - display waiting mail finger (1) - display information about users csh - (default setups anyway) login - (default setups anyway) movemail - (part of GNU-Emacs) -- | () () () | Frank P. Bresz | Westinghouse Electric Corporation | \ /\ / | fpb@ittc.wec.com | ITTC Simulators Department | \/ \/ | uunet!ittc!fpb | Those who can, do. Those who can't, simulate. | ---------- | +1 412 733 6749 | My opinions are mine, WEC don't want 'em.
karl_kleinpaste@cis.ohio-state.edu (11/08/90)
fpb@ittc.wec.com writes:
Well lets see a fast scan if man pages and related things lists as items
which (on SunOS) specifically reference /var/spool/mail/ :
Any reason why one couldn't place symlinks:
cd /usr/spool/mail
foreach i (*)
mv $i ~{$i}/.newmail
ln -s ~{$i}/.newmail $i
end
chmod 555 /usr/spool/mail # to prevent removal of the links.
That's a serious question; I've been debating this for a while. We'd
like users' mail not to occupy space in a public filesystem, but
rather take up space under the area where quotas are enforced.
--karlrickert@mp.cs.niu.edu (Neil Rickert) (11/08/90)
In article <KARL.90Nov7120404@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >Any reason why one couldn't place symlinks: > > cd /usr/spool/mail > foreach i (*) > mv $i ~{$i}/.newmail > ln -s ~{$i}/.newmail $i > end > chmod 555 /usr/spool/mail # to prevent removal of the links. > >That's a serious question; I've been debating this for a while. We'd >like users' mail not to occupy space in a public filesystem, but >rather take up space under the area where quotas are enforced. The only reason I can think of is the following code in /bin/mail (which is usually used for final delivery to the mail spool file). The function safefile() is called to validate the mailbox before the incoming mail is written to it. ------------------------------------------------------------- safefile(f) char *f; { struct stat statb; if (lstat(f, &statb) < 0) return (1); if (statb.st_nlink != 1 || (statb.st_mode & S_IFMT) == S_IFLNK) { fprintf(stderr, "mail: %s has more than one link or is a symbolic link\n", f); return (0); } return (1); } -- =*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*=*= Neil W. Rickert, Computer Science <rickert@cs.niu.edu> Northern Illinois Univ. DeKalb, IL 60115. +1-815-753-6940
gs26@prism.gatech.EDU (Glenn R. Stone) (11/08/90)
In <KARL.90Nov7120404@giza.cis.ohio-state.edu> karl_kleinpaste@cis.ohio-state.edu writes: >fpb@ittc.wec.com writes: > Well lets see a fast scan if man pages and related things lists as items > which (on SunOS) specifically reference /var/spool/mail/ : >Any reason why one couldn't place symlinks: > cd /usr/spool/mail > foreach i (*) > mv $i ~{$i}/.newmail > ln -s ~{$i}/.newmail $i > end > chmod 555 /usr/spool/mail # to prevent removal of the links. >That's a serious question; I've been debating this for a while. We'd >like users' mail not to occupy space in a public filesystem, but >rather take up space under the area where quotas are enforced. This assumes quotas are in the kernel.... That's not so on quite a few machines.... Sequents, R/S 6000's, Sun folks who haven't upgraded.... On a Sun with 4.x, the symlink is a legit way to do things, especially since nasty things happen when /var fills up... but, on the other hand, it's not a good idea on a non-quota machine, since equally nasty things happen when users' home partitions fill up and they try to use a shell with history or some such..... (this assumes some bozo mailer is bombing your machine whilst you're abed asnooze, and others are trying to finish that project at 4am...) This also assumes that people aren't going to break things by chmodding .newmail to something funky, or that the mail delivery program runs setuid root (which it does on USG).... Something else to consider..... I have a cluster of machines, and my users (read: bosses) want to be able to get mail on whatever machine they log into..... any way you try to go about this, a symlink will get shot in the foot. In a nutshell, I think the call on whether to symlink or not is highly system-dependent, and therefore should be left up to the individual S/A..... who should only do so after careful study of the system config. and TFM (and p'raps the net at large.... which is exactly what's going on here). -- Glenn R. Stone glenns@eas.gatech.edu
ron@woan (Ronald S. Woan) (11/09/90)
In article <927@iiasa.UUCP>, wnp@iiasa.AT (wolf paul) writes:
Wolf> Actually, every implementation of NFS I have seen (Ultrix 3.0,
Wolf> SunOS 4.x, Interactive SysV/386) allows you to limit Root Access
Wolf> to to specific machines on a per-filesystem basis, in
Wolf> /etc/exports. The syntax varies from OS to OS, but the concept
Wolf> is the same.
Ahh, but what he meant was that if you had local root, you can change
your own UID and GID to one able to modify or read everyone elses'
files except those with a root owner and only owner rw priveledges. Of
course, you can export it read-only with most NFS's but mail doesn't
really work then...
NFS 4.0 may have provided a fix for this, but I don't remember
offhand...
+-----All Views Expressed Are My Own And Are Not Necessarily Shared By------+
+------------------------------My Employer----------------------------------+
+ Ronald S. Woan woan@peyote.cactus.org or woan%austin@iinus1.ibm.com +
+ other email addresses Prodigy: XTCR74A Compuserve: 73530,2537 +jiml@uwslh.slh.wisc.edu (James E. Leinweber) (11/14/90)
karl_kleinpaste@cis.ohio-state.edu writes: >Any reason why one couldn't place symlinks: ... [making /usr/spool/mail/someone a link to ~someone/.newmail] Mail is a traditional source of security holes in Unix, particularly in the presence of symbolic links. Be very careful around scenarios such as: rm .newmail; ln -s /etc/passwd .newmail echo "cracked::0:0:::/tmp" | mail $USER If the mail delivery agent runs set-uid root, and the directory containing the mail box is writeable by the user, and symbolic links are allowed in mailbox paths, it had better be a community of trusted users. Also, if the user mailbox lives under their home directory and you have disk quotas, you could run into denial of service security risks too. -- Jim Leinweber (608)262-0736 State Lab. of Hygiene/U. of Wisconsin - Madison jiml@sente.slh.wisc.edu uunet!uwvax!uwslh!jiml fax:(608)262-3257
aspgpas@cidsv01.cid.aes.doe.CA (Peter Silva) (11/21/90)
In a heterogeneous environment, WATCH OUT! We have some systems that know about the NFS lock and stat daemons, and others that don't. Net effect: unknown mailer error 1 cannot append to /usr/mail/logname Had to switch it off on the ones that know about it for now (I'm glad it was configurable!) Peter Silva OS Support psilva@cid.aes.doe.ca Dorval Computing Centre (514) 421-4692 Atmospheric Environment Service
mitch@hq.af.mil (Mitch Wright) (11/28/90)
/* * On 5 Nov 90 21:34:21 GMT, * Chet Ramey writes: * */ Frank Bresz writes: Frank> I think delivering mail anywhere but the spool directory is a big Frank> GIANT lose for a great many reasons too numerous to list. I absolute Frank> abhore any suggestion to do so. Chet> List them, please. We have mail delivered to home directories (via a Chet> special delivery program I wrote that people run from .forward files) Chet> and have found it to be the easiest way to solve the problem in a Chet> heterogeneous environment. Well, I have one. o If I finger Joeuser@Podunk.Edu, it will normally let me know what the oldest unread mail message is so I can determine if he's read my mail yet. This is very handy... to me at least ~mitch mitch@hq.af.mil (Mitch Wright) | The Pentagon, 1B1046 | (703) 695-0262 ``A system without PERL is like a hockey game without a fight.'' -- Me -- ..mitch mitch@hq.af.mil (Mitch Wright) | The Pentagon, 1B1046 | (703) 695-0262 ``A system without PERL is like a hockey game without a fight.'' -- Mitch Wright
tage@staff.cs.uit.no (Tage Stabell-Kuloe) (11/28/90)
In article <1990Nov21.145704.10122@cid.aes.doe.CA> aspgpas@cidsv01.cid.aes.doe.CA (Peter Silva) writes: >We have some systems that know about the NFS lock and stat daemons, >and others that don't. Net effect: > unknown mailer error 1 > cannot append to /usr/mail/logname >Had to switch it off on the ones that know about it for now (I'm glad >it was configurable!) >Peter Silva Do the following : 0) Use NFS to mount /usr/spool/mail onto one server. 1) Use MX in BIND to point to the server for all other machines. 2) Read mail to root on that (mail) server. 3) (If you know how to do it) Rewrite sendmail.cf on all the machines to output the (mail)server as sender on all mail. This is not really necessary but makes things more elegant. -- //// Tage Stabell-Kuloe |e-mail : tage@staff.cs.uit.no //// ///Dept. of Computer Science, University|Official: postmaster@cs.uit.no /// //of Tromsoe, N-9000 TROMSOE, NORWAY |Phone : +47-8344053/44041 // / "'oe' is '\o{}' in TeX" |#include: <disclaimer.std> /
news@usenet.ins.cwru.edu (11/30/90)
In article <MITCH.90Nov27190330@hq.af.mil> mitch@hq.af.mil (Mitch Wright) writes: [I wrote asking for the advantages of having a network-wide mail spool] >Well, I have one. > >o If I finger Joeuser@Podunk.Edu, it will normally let me know what the > oldest unread mail message is so I can determine if he's read my mail > yet. This is very handy... to me at least True. That's not a consideration for us for two reasons: we don't run straight BSD finger -- it doesn't scale well to 15,000+-line password files served via YP -- and some paranoid folks around here have complained to the University vice president of information services that divulging such information is a violation of their privacy. Chet -- Chet Ramey ``I die, Horatio'' Network Services Group, Case Western Reserve University chet@ins.CWRU.Edu My opinions are just those, and mine alone.