root@raider.mfee.tn.us (Bob Reineri) (08/06/90)
Is anyone out there successfully using the elm 2.3 PL5 mailer with a stock SCO
Unix 3.2.0 (Update A) system ? Perhaps someone could help.
The problem is in sending mail when the program is run by a user other than
root. For root, everything works fine. Other users get the following message,
after hitting the 's' key to send a message (after composition and editing):
submit: [Permission denied] Can't create text file to be queued.
submit: message submission aborted
I turned on auditing for a moment, and tried the above process. It failed, as
expected, and I then reviewed the audit files with sysadmsh. They revealed that
the failure occurred when submit tried to create a file in the
/usr/spool/mmdf/lock/home/msg directory. The path all the way down to this
directory is owned by user mmdf, and the mode is 700. Pretty restrictive, bu
the submit program runs SETUID to MMDF ! It shouldn't matter, should it ?
Just for grins, I set the mode to 777 all the way down the path, and it
still failed. For some reason, it can chdir to the directory, (as the audit
file shows) but can't create the message file there.
Any help at all would be appreciated. I'm brand new to MMDF, (having used
smail b4) and want to give the stock system a fighting chance. It seems
configurable enough for my needs, and I dont really need all the power of
smail. If I could solve this one problem....
Oh, BTW, the standard mail and mailx programs work just fine for all users....
Bob
--
* RaiderNet Public Access *Middle Tenn's Unix Gateway* Murfreesboro, TN *
* Data:(615)896-8716 896-7905 Voice:(615)849-4390 Mail:PO Box 2371 Zip 37133 *
* Domain: root@raider.MFEE.TN.US UUCP: uunet!mjbtn!raider!root HAM: AB4SU *
* Shell Accounts, Mail/USENET UUCP Links Available -- Send Mail for Details *david@twg.com (David S. Herron) (08/13/90)
In article <9@raider.mfee.tn.us> root@raider.mfee.tn.us (Bob Reineri) writes: >Is anyone out there successfully using the elm 2.3 PL5 mailer with a stock SCO >Unix 3.2.0 (Update A) system ? Perhaps someone could help. I have a vague memory that the most recent version was made to work with it .. but I'm sure the people in c.m.elm will know fer sher.. [After using elm to try to send mail]: > submit: [Permission denied] Can't create text file to be queued. > submit: message submission aborted > >I turned on auditing for a moment, and tried the above process. It failed, as >expected, and I then reviewed the audit files with sysadmsh. They revealed that >the failure occurred when submit tried to create a file in the > /usr/spool/mmdf/lock/home/msg directory. The path all the way down to this >directory is owned by user mmdf, and the mode is 700. Pretty restrictive, bu >the submit program runs SETUID to MMDF ! It shouldn't matter, should it ? >Just for grins, I set the mode to 777 all the way down the path, and it >still failed. For some reason, it can chdir to the directory, (as the audit >file shows) but can't create the message file there. The protections should be: lock owner=mmdf mode=700 lock/home owner=mmdf mode=777 lock/home/*/* owner=mmdf mode=777 (or go+rw) If you run checkup that will run around and check a few things out. Those are included. Note: when checkup prints out a 'mode' like that it drops out the middle digit, 707 instead of 777. Don't take it too literally on that point.. The 700 parent, and 777 below is a security feature. The "trusted programs" in MMDF (submit, deliver and the channel programs (sounds like a rock-n-roll band don't it?)) are the only processes allowed into that area because of this. Weell.. except for random system admins running su'd ;-). But enough digression ... From the message it is definitely getting a permissions problem but setting the directories to 777 I don't know what sort of locking the SCO/MMDF is using .. but if it's the link-locking then there's another directory which may be in a seperate directory tree in which it does it's linking. Oh, mebbe I should explain this. MMDF is an ancient piece of software dating back (in it's original incarnation) to the late '70's. They hadn't thought up things like flock() or fcntl() yet so the only way to do locking was along these lines: make a temporary zero-length file with a random name in a Well Known Directory. derive a name from the file you're locking (based from the dev & ino of the file) Attempt to link the temp file to the derived file name If the link fails then take a few heuristics to see if the locking process might've failed leaving a stale lock. If we think the lock is stale them remove it (after gritting out teeth) and go on trying to act cool and hope that nothing goes wrong. Otherwise the lock succeeded .. Note that UUCP uses a very very very very similar algorithm in the LCK..<tty> and LCK..<host> files ... At any rate, if the Well Known Directory has protection problems then it might've caused the problems you saw. >Any help at all would be appreciated. I'm brand new to MMDF, (having used >smail b4) and want to give the stock system a fighting chance. It seems >configurable enough for my needs, and I dont really need all the power of >smail. If I could solve this one problem.... Good luck.. MMDF really is a good mail system despite how it looks on the systems that SCO sells ya. There's a mailing list at mmdf2-request@relay.cs.net you might wanna get onto >Oh, BTW, the standard mail and mailx programs work just fine for all users.... Yeh.. that makes this a bit of a stumper .. Does the documentation in ELM really & truly CLAIM to work with MMDF? There is a sendmail emulator in MMDF which works pretty well and in general the user agents which do with with MMDF do work very well. -- <- David Herron, an MMDF weenie, <david@twg.com> <- Formerly: David Herron -- NonResident E-Mail Hack <david@ms.uky.edu> <- <- Sign me up for one "I survived Jaka's Story" T-shirt!