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 *6sigma2@polari.UUCP (Brian Matthews) (08/08/90)
In article <9@raider.mfee.tn.us> root@raider.mfee.tn.us (Bob Reineri) writes: |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 When Configure asks where submit is, tell it /usr/lib/mail/execmail. This seems to work for me. -- Brian L. Matthews blm@6sceng.UUCP
drew@lethe.uucp (Drew Sullivan) (08/08/90)
Yes, I just got it work. There is a program in /usr/mmdf/bin called 'checkq' or some such thing. (I can't remember the exact name, but it is there) When run it checks all of the file perms for the mmdf system. Other than ignoring the fact the v6mail doesn't exists, fallow all of it's sugestions includeing changing a who lot of directories from 700 to 707 (yes 707, rwx---rwx) It look strange but that is what it took to get it to work. -- -- Drew Sullivan, <drew@lethe.uucp>
john@beaudin.UUCP (John Beaudin) (08/08/90)
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. >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've been thru this and netters helped me out. Run /usr/mmdf/bin/checkup. It will notify you of probable permission problems. -- My .signature is awaiting apropriate display technology
6sigma2@polari.UUCP (Brian Matthews) (08/09/90)
In article <1990Aug8.014440.18541@lethe.uucp> drew@lethe.uucp (Drew Sullivan) writes: |change a whole lot of directories |from 700 to 707 (yes 707, rwx---rwx) It look strange but that is |what it took to get it to work. That may be fine for some systems, but I don't want everyone in the known universe to be able to muck with my mail queues. I use /usr/lib/mail/execmail, and it seems to work fine, with rn, Bnews, and elm, with no nasty permission changes. -- Brian L. Matthews blm@6sceng.UUCP
walter@mecky.UUCP (Walter Mecky) (08/11/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 only have SCO UNIX 3.2.0, but I have "rn" ...
< 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 had the same problem, if I wanted to reply in the newsreader "rn".
< 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 ?
Yes, but submit seems to do setuid(getuid()) for reading the file
of the user. And it seems it does this at the wrong time ...
< 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 reason it, that you must give 777 to all the file in
/usr/spool/mmdf/lock/home, especially to the directories q.local, tmp
and addr.
< Any help at all would be appreciated. I'm brand new to MMDF
Hope this is a help.
--
Walter Mecky [ walter@mecky.uucp or ...uunet!unido!mecky!walter ]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!
allbery@NCoast.ORG (Brandon S. Allbery KB8JRR/KT) (08/14/90)
As quoted from <7744@gollum.twg.com> by david@twg.com (David S. Herron): +--------------- | 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. +--------------- If you have networking, perhaps. SCO doesn't seem to have provided the smtp channel program... and I'm afraid to install a real MMDF because of SCO *nix's authorization database. (They neglected to give us the reference manuals as well....) ++Brandon -- Me: Brandon S. Allbery VHF: KB8JRR/KT on 220 (soon others) Internet: allbery@NCoast.ORG Delphi: ALLBERY uunet!usenet.ins.cwru.edu!ncoast!allbery America OnLine: KB8JRR