Top Secret

[Content corrected 2018-01-16 by OP]

I have a need at one client to set up dataset-access rules as follows:

• Everyone has DATASET(HLQ.) ACC(READ)
• Everyone has DATASET(HLQ.%.) ACC(ALL)—they can set up any datasets with their own ACID in the second node of the DSN.

USERB can thus read DATASET(HLQ.USERA.), with this exception:

• No user has access to HLQ.USERA.PRIVATE.

I've tried to set this up in various ways, but it isn't working as I expected.  My first attempt was this (listed in what I think should be most specific to least):

  PER(profile) DATASET(HLQ.*.PRIVATE) ACC(NONE)

  PER(profile) DATASET(HLQ.%.) ACC(ALL)

  PER(profile) DATASET(HLQ.) ACC(READ)

That's clearly wrong; TSS thinks HLQ.*.PRIVATE is more specific than HLQ.*, and prevents USERA from any access to HLQ.USERA.PRIVATE.  So I added an extra rule:

  PER(profile) DATASET(HLQ.%.PRIVATE) ACC(ALL)  /* added this one

  PER(profile) DATASET(HLQ.*.PRIVATE) ACC(NONE)

  PER(profile) DATASET(HLQ.%.) ACC(ALL)

  PER(profile) DATASET(HLQ.) ACC(READ)

I expected that HLQ.%.PRIVATE would be considered more specific than HLQ.*.PRIVATE—and therefore that USERA could maintain HLQ.USERA.PRIVATE but one else could see it—but no, HLQ.*.PRIVATE is being given priority over HLQ.%.PRIVATE.  This prevents anyone from creating his own PRIVATE dataset.

So, two questions:

1) Is it not an error that TSS should evaluate * before %?

2) Regardless of the answer to #1, what must I do to institute the desired security?

Good morning Bob,

I do not know if there is something special for the word private because this doesn't make sense to me.  The first permit should allow read access to HLQ.USERA.PRIVATE.  Of course without seeing listings or a trace we cannot exactly determine what is being used to allow/disallow acccess.   Can you please open a case on this and include a sectrace of the acid trying to access HLQ.USERA.PRIVATE?  Also include the error message and once we see the trace we will need a listing of the acid, DATA(ALL,PROFILES,SORT).  On another thought, have you tried this in TSSSIM?  If so what was the outcome.

Cheers,

   ~Eileen~

Hi, Eileen; Bob Bridges again, just using the ARC ID.  First, I apologize:  I see that in my first post I botched the fourth rule, the one I added late.  Apparently I cut-and-pasted it and then forgot to modify it properly, which confused the issue considerably.  I'll go back and edit the first post.  The below four rules are what I was using, and what I think should work.  About your questions:

1) "PRIVATE" is just part of the DSN; it has no special meaning except to make the example clearer, and in fact it's not the actual DSN used by my client.

2) You say "The first permit should allow read access to HLQ.USERA.PRIVATE", but I'm pretty sure you're mistaken; the first permit in the original, uncorrected post isn't the one that TSS would use, since the others are more specific, ie better matches.  It seems to me that TSS should use the first one below (ARC.%.PRIVATE) and grant ACCESS(ALL), but in fact it's using ARC.*.PRIVATE and granting ACCESS(NONE).

3) Yes, I used TSSSIM to verify what's happening.  Here's the combined rule set, listed (as I understand it) from most specific to least:

  PER(profile) DATASET(HLQ.%.PRIVATE) ACC(ALL)

  PER(profile) DATASET(HLQ.*.PRIVATE) ACC(NONE)

  PER(profile) DATASET(HLQ.%.) ACC(ALL)

  PER(profile) DATASET(HLQ.) ACC(READ)

At least, that's what ~I~ think should be the order.  When I have USERA try to access HLQ.USERA.PRIVATE, I think TSS should use the first rule and grant ACCESS(ALL); but TSSSIM says that the second rule mandates ACCESS(NONE).

I thought maybe someone here would explain what I was missing, but I'll go open a case.

Bob,

You should be able to accomplish what you are wanting by using two (2) profiles, as indicated following -

TSS CREATE(PRF1) NAME('1st Profile') DEPARTMENT(DEPT1)

TSS PERMIT(PRF1) DSNAME(HLQ.%.) ACCESS(ALL)

TSS CREATE(PRF2) NAME('2nd Profile') DEPARTMENT(DEPT1)

TSS PERMIT(PRF2) DSNAME(HLQ.*.PRIVATE) ACCESS(NONE)

TSS PERMIT(PRF2) DSNAME(HLQ.) ACCESS(READ)

When adding the profiles to an accessor ID, the ordering is of course, critical.

Please note that this approach will NOT work if you are running with AUTH(MERGE).

John P. Baker

Bob Boerum sent me a definitive answer on this.  For the benefit of anyone else who has this question (probably no one), here's what he gave me:

1) The longer specification is considered more specific than the shorter, of course.

2) If they're the same length (as with HLQ.%.PRIVATE and HLQ.*.PRIVATE), the % would be evaluated first, unless —

3) ...unless one of them specifies ACCESS(NONE), in which case that takes precedence.

This explains why DATASET(HLQ.*.PRIVATE) ACC(NONE) is being taken instead of DATASET(HLQ.%.PRIVATE) ACC(ALL), so TSS is indeed Working As Designed.

A clarification to #2 above:

If multiple matching permits are found with the same length resource name, the one that allows access is used unless one of the permits has ACCESS(NONE). This is regardless of any masking characters.