On 6/8/2012 6:09 AM, rob@xxxxxxxxx wrote:
Could be any number of things. One real popular problem is IBM started
changing, and shipping, the '/tmp' directory differently a few OS' back.
If you display the attributes on it you may see
Restricted rename and unlink . . . . . : No
IMO Yes is bad.
It's bad from a backward-compatibility point-of-view, but given the
purpose of that directory, it's the right thing to do. Turning off
restricted rename and unlink is a security hole.
It may be a Linux standard for a p... poor implementation
of QTEMP, but it just doesn't work for the IBM i email products. What
this means is that, if someone else creates an entry in that directory,
like you calling QTmmSendMail
It's not a "Linux standard," though Linux does it, it really originates
with Unix. Remember: Unix is very old, older than the System/32 --
nearly as old as the IBM System/3. Very old. When something evolves
over such a long period of time, it develops legacy quirks, and /tmp is
an example of one. It was a reasonable solution in 1969, but not so
reasonable today. Linux attempts to be Unix-like, and be compatible
enough that Unix software can be run on Linux -- so it has to preserve
this legacy behavior. In fact, IBM i has a /tmp directory for the same
reason!
Originally, the Unix /tmp was open to everyone.. This was discovered to
be a huge security hole in the Unix community because lots of software
uses /tmp to store data while programs are processing them. Since /tmp
is shared by everyone, it needs to be publicly accessible, so a
miscreant can use his access to /tmp to gain access to other people's
(possibly confidential) documents. Restricted rename and unlink solves
that problem.
Since IBM i runs Unix software (via PASE, QShell, etc) in growing
volume, it should have the same security.
QtmmSendMail is a horribly designed API. There's absolutely no good
reason for it to pass a file to another job that runs with a completely
different authorization. This process creates all sorts of problems,
such as issues with the caller being able to generate the next e-mail
without stepping on the first one, or security issues where an e-mail
message (which has the potential to be confidential) has to be publicly
readable so that the background user profile can read/delete it. The
fact that it works asynchronously means that failures can occur without
notifying the calling program, which makes it extremely difficult to
troubleshoot. It's a poor design.
My own implementation uses sockets to talk to the SMTP server. Since
the data flows through a socket (rather than a temporary file) there's
no similar security/privacy concern. Since the program can wait for the
mail server to receive and accept the mail, it has the ability to see
any errors that are found, and relay them back to the programmer/user.
There's no problems with reusing the same file, since the data has
already been moved into the MSF queues before control is returned to
your program.
But, anyway... IMHO, criticizing the "restricted rename and unlink"
setting on /tmp seems like you're pointing blame in the wrong
direction. The problem isn't that feature -- the problem is that you're
using a bad API, and using the general-purpose /tmp directory (instead
of your own direcory like /var/spool/qtmmsendmail_queue) to queue up
mail for it.
Just my 2 cents.
midrange.com
