[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Authorities in the IFS (DCM)
Sender: "McKinnell, Andy" <AMcKinnell@xxxxxxxxxxxxxxxx>
The only downside is the use of disk space for the journal receiver that the qaudjrn uses. You can experiment with this on your development box. Look at the system value qaudctl and see if you have the audit journal turned on. The qaudjrn needs to exist.
Try dspjrn qsys/qaudjrn. You should get some entries if it is.
Andy
-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of ian
Sent: Friday, February 11, 2005 3:47 PM
To: ftpapi@xxxxxxxxxxxxx
Subject: RE: Authorities in the IFS (DCM)
Sender: "ian" <ian@xxxxxxxxxxxxxxxxx>
Andy,
This method is new to me.
I will have a chat with the Users to see if they will give it a go.
Are there any down-sides in setting on this logging for a limited time ?
Also, is the analysis of the journal entries straight forward?
As I can not reproduce the problem on my development box, I will have to
persuade the User to turn it on in a live environment.
... and you know what iSeries IT Managers may think about that :-)
Regards,
Ian Patterson
-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of McKinnell, Andy
Sent: 11 February 2005 18:04
To: ftpapi@xxxxxxxxxxxxx
Subject: RE: Authorities in the IFS (DCM)
Sender: "McKinnell, Andy" <AMcKinnell@xxxxxxxxxxxxxxxx>
If you are journaling authority failures in the qaudjrn, create the problem
and look for the journal record with the AF code associated with the job you
are running. This should tell you the object and user that are having the
problem. You can turn this on with the system value qaudlvl.
Andy McKinnell
-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of ian
Sent: Friday, February 11, 2005 12:25 PM
To: ftpapi@xxxxxxxxxxxxx
Subject: RE: Authorities in the IFS (DCM)
Sender: "ian" <ian@xxxxxxxxxxxxxxxxx>
Thanks Scott,
Firstly, There are no other cert stores being used other than *SYSTEM. That
a definite.
I don't get the problem on my box.
Here is the QSHELL info:
-rw------- 1 QSYS 0 75080 Aug 3 2004
/QIBM/Userdata/ICSS/CERT/SERVER/DEFAULT.KDB
and here is the info from WRKLNK:
Data --Object Authorities--
Opt User Authority Exist Mgt Alter Ref
*PUBLIC *EXCLUDE
QSYS *RW X X X X
which surprises me because I can use the API without a problem and I'm not
in a group (but my profile Type is QSYSOPR).
I will collect this info from other installations to see if I can get to the
bottom of it.
Regards,
Ian Patterson
-----Original Message-----
From: owner-ftpapi@xxxxxxxxxxxxx [mailto:owner-ftpapi@xxxxxxxxxxxxx]On
Behalf Of Scott Klement
Sent: 11 February 2005 16:50
To: ftpapi@xxxxxxxxxxxxx
Subject: Re: Authorities in the IFS (DCM)
Sender: Scott Klement <sk@xxxxxxxxxxxxxxxx>
> We are experiencing some difficulties in authorities in the IFS which
appear
> to be random, but I am sure they are not.
> We use Scotts httpapi in ssl mode, which in turn evokes a usage of the
DCM.
> The path to the DCM is:
> /QIBM/USERDATA/ICSS/CERT/SERVER/DEFAULT.kdb
That's the path of the key database in the *SYSTEM certificate store.
You're right that this is part of the DCM, but it's not all of it.
> Changing the *PUBLIC authorities for server and default fixes the problem.
>
> My question is, why do we not get this error for all Users ? Our
experience
> is something like 50/50 get/do not get/ the error.
Is it possible that these other users are using certificates that are not
in the *SYSTEM certificate store?
Another thought: Maybe they've got group access to the file? Every file
in the IFS has 3 levels of authority: Owner, Group & Public. You said
that the file is *PUBLIC *EXCLUDE, so that rules out "Public". And they
can't ALL be the owner of the file. So, that leaves group...
You can use QShell to see who the owners are and what their level of
authority is:
STRQSH
ls -l /QIBM/UserData/ICSS/CERT/SERVER/DEFAULT*
This should show something like:
-rwxrwxr-x 1 QSECOFR QSYS 110080 Oct 8 17:54
/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.KDB
-rwxrwxr-x 1 QSECOFR QSYS 5080 Aug 5 2004
/QIBM/UserData/ICSS/CERT/SERVER/DEFAULT.RDB
In this example, the owner is QSECOFR and the group is QSYS. At the start
you see '-rwxrwxr-x' that indicates the permissions for the three
different classes of users. The first 3 'rwx' is QSECOFR's permissions to
the file. He's got read, write and execute. The next 3 are QSYS's
authorites 'rwx' again, meaning read/write/execute. The last 3 are the
public's authorities. 'r-x' means read & execute (but not write!)
> There may be something else that affects the access to default.kdb other
> than the authorities I have described above.
> I note that QSYS retains all rights. Is it possible that some users are
> adopting QSYS ?
Adopted authority won't work in the IFS. However, user profile swapping
would work. Or, having QSYS assigned as their group profile or a
supplemental group would also work.
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------
-----------------------------------------------------------------------
This is the FTPAPI mailing list. To unsubsribe from the list send mail
to majordomo@xxxxxxxxxxxxx with the body: unsubscribe ftpapi mymailaddr
-----------------------------------------------------------------------