gregc@cgl.ucsf.edu (Greg Couch) (07/12/89)
A bit of background: we share a password file amoung several 4.3 systems
and restrict access to a particular system by having login fail if the
user doesn't have a home directory on that system. Thus we don't want
users to get mail on machines they can't access.
Enclosed is a small enhancement to reject mail to users that don't have
home directories. Depending on how your site manages accounts, you might
want to disable mail to users with non-standard shells or to users whose
password entry is "*" or somesuch.
This patch works for sendmail versions 5.59 and 5.61.
- Greg Couch
gregc@cgl.ucsf.edu
postmaster@cgl.ucsf.edu
------
sendmail/src/recipient.c:
------
RCS file: RCS/recipient.c,v
retrieving revision 1.1
diff -c -r1.1 recipient.c
*** /tmp/,RCSt1024920 Tue Jul 11 15:09:13 1989
--- recipient.c Tue Jul 11 14:52:40 1989
***************
*** 303,309
/* warning -- finduser may trash buf */
pw = finduser(buf);
! if (pw == NULL)
{
a->q_flags |= QBADADDR;
giveresponse(EX_NOUSER, m, CurEnv);
--- 303,309 -----
/* warning -- finduser may trash buf */
pw = finduser(buf);
! if (pw == NULL || !safefile(pw->pw_dir, pw->pw_uid, S_IEXEC))
{
a->q_flags |= QBADADDR;
giveresponse(EX_NOUSER, m, CurEnv);roy@phri.UUCP (Roy Smith) (07/12/89)
In article <11680@cgl.ucsf.EDU> gregc@cgl.ucsf.edu (Greg Couch) writes: > we share a password file amoung several 4.3 systems and restrict access > to a particular system by having login fail if the user doesn't have a > home directory on that system. Thus we don't want users to get mail on > machines they can't access. Enclosed is a small enhancement to reject > mail to users that don't have home directories. Yuck! This really seems rather needless. Why not just share /usr/lib/aliases files as well? Have each person have an alias pointing to the machine where their home directory is. Not only is that much simplier than hacking sendmail, but it also allows people to send mail to somebody without having to know which machine they are on. -- Roy Smith, Public Health Research Institute 455 First Avenue, New York, NY 10016 {allegra,philabs,cmcl2,rutgers,hombre}!phri!roy -or- roy@alanine.phri.nyu.edu "The connector is the network"
gregc@cgl.ucsf.edu (Greg Couch) (07/14/89)
I should have given a bit more background. We sort of share the alias file among the various hosts by routing all mail that only has a user in the address through the mail gateway for our lab. All outgoing mail appears to be from the mail gateway so we're free to change any of the other host names at will. Mail to a particular host will be delivered on that host so a local user may pick which host he wants to read mail on. Consequently, with sharing of the password file and the not allowing logging in to hosts that the user doesn't have a home directory on, mail needed to be disabled to accounts that don't have home directories. True sharing of the alias file would solve the above problem, except: When we turn off an account, we don't remove a user from the password file (just disable the password, change the shell to /noshell, and rm -rf the account). The local mailer can't be changed to reject mail to disabled accounts because sendmail thinks that all local mailer errors are temporary. Thus sendmail had to be changed to not deliver the mail in the first place. This has the nice side effects of having the SMTP VRFY command return "User Unknown" for disabled accounts and of causing errors in mailing lists that include that user. If you have the second problem but not the first, you could alter my change from checking if the home directory exists to checking if the shell is /noshell (or whatever your local convention is). Further followups have been redirected to comp.mail.sendmail. - Greg Couch gregc@cgl.ucsf.edu gregc@ucsfcgl.bitnet
sysruth@helios.toronto.edu (Ruth Milner) (07/14/89)
In article <3853@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >In article <11680@cgl.ucsf.EDU> gregc@cgl.ucsf.edu (Greg Couch) writes: >> Thus we don't want users to get mail on >> machines they can't access. > > Yuck! This really seems rather needless. Why not just share >/usr/lib/aliases files as well? Have each person have an alias pointing to >the machine where their home directory is. Yuck! And then every time you add a new user you have to append an alias onto /usr/lib/aliases and tell every system on which they have no home directory to run newaliases. Not to mention removing the alias when you remove the user (yes, I know this is not strictly necessary, but on a big system you can wind up with a very large file very quickly, and after a year or two you have no idea offhand who's really there any more). Personally, I'd rather hack sendmail once every 6 months when I make a new version. Of course, if you add an account about once a month or less, it's no big deal. When you are adding as many as several accounts per week, as we do, it is not nice at all. What we do is have a small hack to sendmail (I think) to make it read a file called "localdelivery" on startup. Any system listed in this file on a server has its mail received by that server. And the nameserver data has an MX record for that system pointing to the server. We do this for a) diskless clients and b) systems which can't run a locally-compatible version of sendmail. That way, when we add a new *system* we make one change each to two files, and forever after all mail for those systems is received centrally. Servers share the /usr/spool/mail area with their clients so the mail can be read from the clients as well. Works very nicely. Access to a system is determined by who owns it: everyone is authorized to use a Consortium-owned computer; systems privately owned restrict access to the people in the owner's group by giving everyone else a nonexistent shell. To each his/her own, I guess. -- Ruth Milner UUCP - {uunet,pyramid}!utai!helios.physics!sysruth Systems Manager BITNET - sysruth@utorphys U. of Toronto INTERNET - sysruth@helios.physics.utoronto.ca Physics/Astronomy/CITA Computing Consortium
rcodi@chudich.co.rmit.oz (Ian Donaldson) (07/14/89)
From article <11680@cgl.ucsf.EDU>, by gregc@cgl.ucsf.edu (Greg Couch): > A bit of background: we share a password file amoung several 4.3 systems > and restrict access to a particular system by having login fail if the > user doesn't have a home directory on that system. Thus we don't want > users to get mail on machines they can't access. > > Enclosed is a small enhancement to reject mail to users that don't have > home directories. Depending on how your site manages accounts, you might > want to disable mail to users with non-standard shells or to users whose > password entry is "*" or somesuch. A related problem is when one of the disks containing the users' home directory drops dead and the machine is brought up without that disk online. The ".forward" files that users' have aren't accessable anymore, so the mail ends up in /usr/spool/mail. When the disk then come up, and the home directories return, the ".forward" files do also, and people wonder (on other machines) where their mail went to... This fix would cause such mail to bounce, which at least tells somebody (the sender) what has happened to it. What I think would be preferable in this case is for the mail to be held-over (in /usr/spool/mqueue) until the home directory of the recipient can be accessed, so that a ".forward" file can be searched for. I think that the fix in this article should involve something along the lines of... if /usr/spool/mail/user is mode 000 then no mail should be receiveable for that user on this machine, and so bounce the mail. This makes it easy to tune... just create a mail box file, mode 000 for such users! Put some crap in it if you have scripts that clean out empty mail boxes upon reboot... If the user had a mailbox already there, then the user could even turn off/on the feature himself via chmod(1) (since he owns the mailbox file) The mod would probably go in BSD /bin/mail, to check for mode 000 files. Ian D
cudcv@warwick.ac.uk (Rob McMahon) (07/15/89)
In article <844@helios.toronto.edu> sysruth@helios.physics.utoronto.ca (Ruth Milner) writes: >In article <3853@phri.UUCP> roy@phri.UUCP (Roy Smith) writes: >>Why not just share /usr/lib/aliases files as well? Have each person have an >>alias pointing to the machine where their home directory is. > >Yuck! And then every time you add a new user you have to append an alias >onto /usr/lib/aliases and tell every system on which they have no home >directory to run newaliases. Not to mention removing the alias when you >remove the user ... > >Personally, I'd rather hack sendmail once every 6 months when I make a >new version. > >Of course, if you add an account about once a month or less, it's no big >deal. When you are adding as many as several accounts per week, as we do, >it is not nice at all. We are constantly adding and deleting accounts, sometimes say 250 in a block, always 10s and sometimes (like at the start of a term) 100s in a week. We just run a script every night that snarfs the information from the password databases, knocks up an alias file, and rdist's it around all the machines. It adds automatically generated personal aliases too (you can mail me at <R.McMahon@uk.ac.warwick> ...). There are currently 13395 aliases in our alias database, and it requires virtually no manual intervention (only to say add a new mailing list). Alternatively you could add a couple of lines to your makeuser/deluser programs to change the alias file. >... when we add a new *system* we make one change each to two files, and >forever after all mail for those systems is received centrally... Our diskless machines share alias files as well as /usr/spool/mail with the server. Adding a new diskless machine requires precisely zero changes. Adding a new server requires one change to the makefile that distributes the alias files. >To each his/her own, I guess. Of course, but I think there are easier/cleaner alternatives than you've chosen. Rob -- UUCP: ...!mcvax!ukc!warwick!cudcv PHONE: +44 203 523037 JANET: cudcv@uk.ac.warwick ARPA: cudcv@warwick.ac.uk Rob McMahon, Computing Services, Warwick University, Coventry CV4 7AL, England