Re: Problem with V5R3 - /tmp directory & qtmmSendMail

[Scott Klement <klemscot@xxxxxxxxxxxx>]

Hi Kevin,

[SNIP]
> We feel that this change is not backwards compatible. Either the new
> attribute on /tmp should have defaulted to NO or the QMSF user profile
> and/or job should somehow be allowed to unlink the temporary stream files
> after it has processed them no matter where they are located.
[SNIP]

All of the Unix systems have already made this change as well. It's a
security thing -- since /tmp is always available for ANYONE to write to,
the system restricts your ability to delete someone else's files.

Worse, if you can delete someone elses files, you can also create your own
file with the same name.  The potential exists for you to delete another
job's temp file, create your own version that you have "read" permission
to, and then let the other job write data to it.   It's possible that
someone could use that mechanism to gain access to confidential
information.

So, yes, this does create some incompatibilities -- that's why it was
published in the V5R3 memo to users in the first place -- but I think that
it's necessary.

It should be relatively easy to change your software...  after creating
the file, chown() it to QMSF, so that QMSF has the ability to delete it.  Or
perhaps even better -- after the API is finished with the file, have the
original user profile delete it.

Just my opinion, of course.