Re: On one particular box, Tomcat 7.0.25 runs just fine, but 7.0.47 crashes on takeoff -- some authority problem

On 09-Dec-2013 11:00 -0800, James H. H. Lampert wrote:

<<SNIP>>
The T-AF audit entry shows (and I'm no longer bothering to "change
names to protect the innocent"):

What a relief! Obfuscating makes reviewing difficult, and when done for anything other than legitimate protection of privacy or true trade secrets, hardly seems worthwhile.

00001 'A*N *N *STMF QP0ZSPWP WTADMIN '
00051 '280199 WTADMIN 0000'
00101 '000 '
00151 ' '
00201 ' '
00251 ' nP8 ry '

. . .

00801 ' nP8 ry QASP01 00001 USENU Y '
00851 ' /wintouch/tomcat/bin/startup.sh '

Which would seem to indicate that it's the startup shell script itself
that has the authority problem.

So looking at the paths using the QShell "ls" command, I get:

cd /wintouch/tomcat/bin
$
ls -l startup.sh
-rw-rw-rw- 1 WTADMIN 0 1961 Oct 18 13:19 startup.sh

for the 7.0.47 version, which has the authority failure, and

cd /wintouch/tomcat.bak/bin
$
ls -l startup.sh
-rw-rw-rw- 1 WINTOUCH 0 1961 Jun 15 2012 startup.sh

for the 7.0.25, which looks exactly the same, except for the owner
and the date, and yet it works. <<SNIP>>

From memory only, because I rarely muck with that stuff, and so easily forgotten until I have to dig-in again [which I do not desire to do presently]...

The dashes in the above output from the ls requests, indicate that the /owner/ is missing execute capability\authority; i.e. there is no 'x' shown for fourth byte of the string '-rw-rw-rw-'. That is the equivalent of, IIRC, a chmod mask of 666. Thus to enable WTADMIN to execute the file, the authority mask for the file must be changed to be 766 to effect the string appearing as '-rwxrw-rw-'. Although seeing 'w' in any other position than for owner's authority seems suspect, because one might expect that the script should not be able to be modified by anyone else.? Also, this apparently confirms the user WTADMIN does *not* have the /All Object/ special authority.?

So presumably, the failure with 7.0.47 running with WTADMIN is correct\expected.

By that same analysis however, the reason the 7.0.25 runs with the user WTADMIN or any other user, would function without a permission error is unclear to me, with just that information. If the 7.0.25 were run with user WINTOUCH, then that would be expected to fail the same way. The exception I expect, is if the user running the 7.0.25 has the Special Authority (SPCAUT) of *ALLOBJ [effective root authority] to avoid the issue of authority. What user does that processing run with, and does that user have SPCAUT(*ALLOBJ)?