The user is merely authenticating to the web server.  I don't believe it
has anything to do with resource authorization.  It is the web server
job that is accessing the objects.  Hence, the profiles the web server
run under need authority to whatever objects they are serving.  Those
profiles would be QTMHHTTP and, for CGIs, QTMHHTP1.

This is both good and bad.  Good as resource security is easier to
maintain: create an object, allow QTMHHTTP RX access, done.  No need to
use a group profile and no need to update object authorities as new
users are added to the system/web app.  Bad because now anyone who
authenticates against the web server can access the resource if they
know the proper URL -- even if they would not normally be authorized to
that object.

John A. Jones
Americas Security Officer
Jones Lang LaSalle, Inc.
V: +1-630-455-2787 F: +1-312-601-1782
John.Jones@xxxxxxxxxxxxxxxxxxxxxxx

-----Original Message-----
From: Derek Butler [mailto:DerekB@xxxxxxxxxxxxx] 
Sent: Thursday, August 12, 2004 11:12 PM
To: 'web400@xxxxxxxxxxxx'
Subject: [WEB400] Apache at V5R3 - Access to IFS object denied

Hi,

I have an AS400 set up at V5R3 with Apache and am trying to download an
object from the IFS using IE5.5 or greater.
The user is required to have authority to the folder containing the
object and is prompted for an AS400 userid and password.

The equivalent scenario works correctly on a non-Apache HTTP server at
V4R5 and V5R1.

When trying to access a file on the IFS via the web I am receiving the
following message in the error log for the Apache Sever:

 (3401)Permission denied.: ZSRV_MSG064B: access to
/download/download1/test.zip denied.

The test.zip object has public access permissions.
The "download1" folder containing the object does not have public
read/write execute permissions on it but does have these permissions for
another user profile. In the server confguration file, the download
folder is password protected as follows:

<Directory /download/download1/>
AllowOverride None
AuthName download
ProfileToken off
AuthType Basic
order allow,deny
allow from all
UserID %%CLIENT%%
PasswdFile %%SYSTEM%%
require valid-user
</Directory>

The desired functionality is that when the user enters the url
http://hostname/download/download1/test.zip 

The user is prompted for a username and password. This username is used
to check the folder's permissions before allowing access to the file.

If I add QTMHHTTP to the list of users with execute permission for the
download1 folder, the problem seems to be resolved.

Why does V5R3 (with Apache) seem to require QTMHHTTP to be specified on
an IFS folder in order for the above Apache configuration to come into
effect?

Is the access to the IFS folder take precedence over the protection
setup in the Apache Server configuration file?

Has security been modified in this respect?

Regards
Derek Butler
Analyst/Programmer
Neller Software
Tel: +61 (08) 8139 1859
email:derekb@xxxxxxxxxxxxx


This email is for the use of the intended recipient(s) only.  If you have 
received this email in error, please notify the sender immediately and then 
delete it.  If you are not the intended recipient, you must not keep, use, 
disclose, copy or distribute this email without the author's prior permission.  
We have taken precautions to minimize the risk of transmitting software 
viruses, but we advise you to carry out your own virus checks on any attachment 
to this message.  We cannot accept liability for any loss or damage caused by 
software viruses.  The information contained in this communication may be 
confidential and may be subject to the attorney-client privilege. If you are 
the intended recipient and you do not wish to receive similar electronic 
messages from us in future then please respond to the sender to this effect.


As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.