Why not let users own their own datasets?

[Robert Bridges]

I see in the TSS Users' Guide (r15): "TSO users do not automatically have access to data sets starting with their ACID. The security administrator must establish ownership by adding the data set prefix to an ACID and then permitting it to the user."  But isn't it simpler than that?  Why not just let that ACID own those datasets?  I'm not talking about a change to TSS' assumptions to match RACF, I'm just saying the sec admin can:
1) Create ACID XYZ, and then
2) TSS ADD(XYZ) DSN(XYZ.)

Any reason why not?  Seems pretty straightforward to me.

[Kevin Segreti]

Hi Robert,

This is a great question.  Owning resources in Top Secret can be very dangerous.  There is no verification prompt when you use the TSS ADD command.  If you mistype the ADD command, you can create an owner shorter than what you intended, which would cause more resources to be owned, which could cause operational issues.  

The manual is a guideline, but there are other ways to accomplish this.  Not every customer can own each TSO ID because of conflicts in other dataset names, which are already owned at a shorter length.  Those customers utilize dataset permission of DSN(%.) ACCESS(ALL) in the ALL record to grant them access to their own datasets as % is a masking character that resolves to the user's TSO ID.

Lastly, if it is the number of commands you are concerned with, you can accomplish what the two commands in the manual do with one command.  You can make a user an owner of their dataset using the create command and not needing a second one.  The syntax would be as follows:

TSS CRE(XYX) NAME('xyz') type(USER) pass(pas,,exp) DEPT(XYZDEP) DSN(XYZ) 

The last DSN keyword on the create command would act like the ADD command and make the user an owner of their dataset at the time of creation.

I hope these answers help.  Please contact me if you wish to discuss further.

Kevin

[Robert Bridges]

Ok, a few comments, Kevin:

Notice my example was not ADD(XYZ) DATASET(XYZ) but ADD(XYZ) DATASET(XYZ.).  Seems to me that using that syntax, every customer CAN own his own HLQ; there's no danger there of the user owning other datasets, and if the admins have already done "ADD(<deptacid>) DATASET(X), it's easy to add UNDERCUT to allow a user to own his own datasets.

I thought maybe someone would say that adding an ownership for each inidividual user ACID would gum up the TSS database.  It's not clear to me, though, whether DATASET(%.) in the ALL record wastes more processing time or DATASET(XYZ.) in each user ACID wastes more space.

On the other hand, what happens if my user XYZ has XA DATASET X ACC(NONE) in one of his profiles and DATASET(%.) in the ALL record?  The profile is searched first, but the ALL entry is ownership not permission; which governs?  I suppose I could easily test it.

Nah, not the number of commands.  I usually end up writing a create-ACID REXX exec to save the typing, and adding the dataset ownership, the TSO alias and so on would certainly be part of it.  I did not know, however, that I can include DATASET(XYZ.) in the CREATE command; thanks.  I suppose that applies to any argument that goes with the ADD command?

[Kevin Segreti]

You are right my eyes are going, and I did miss you had your example delimited, but I still stand by my initial warnings.  I feel the need to warn even further about using the undercut keyword.  If TSS is warning you that your ADD command will not work without an undercut, that is an indication you are already conflicting with existing ownerships.  Issuing the undercut moves all other owner records under the one acid you are issuing the command for.  That can over-entitle the ACID as the owner has full access to all resources it owns.  In addition, if you need to undercut access, you have to be scoped over the resource that would be combined with the undercut command.  That would require you to have TSS ADMIN access beyond the scope of your own ID.

Regarding your question about the ALL record, adding resources to the ALL record does not cause performance problems.  The ALL record is loaded in memory, not the security file.  The AUTH setting in Top Secret has more of an effect on how many resources each SAF call utilizes, but we also have caching facilities that make the processing efficient.

I would not worry about space being used. Depending on your TSS Security file's version and feature set, you should have 256k to 1024k of space on each ACID individually. The amount of space these permissions or ownership records take up is very small.  

For the issue regarding conflicting permission, one note I should make is you cannot have permission of DSN(X).  Ownership records must be at least two characters in length, which means permissions have to be at least two characters in length.

The answer to your final question is yes.  You can place anything on the create command that you would use a TSS ADD command for.  That would be Profiles, Groups, Attributes, FTD fields and segments, and installation data fields.

Kevin

 

[Robert Bridges]

You're right, I forget about the two-char limit for ownership.  My example didn't look quite right to me even when I typed it, not because I remembered what the manual said but probably because in actual ownership I've always seen it with two.

About your warnings, though, I don't see it yet.  My understanding of ownership is perhaps too simple:

1) Long ago and far, far away an admin assigned assigned dataset ownership to a certain department code: "add(dept99) dsn(x*)".

2) Today an admin creates user ACID XYZ and gives him ownership of his own datasets:  "add(xyz) dsn(xyz.) undercut"

In TSS, then, DEPT99 owns most datasets named X, but any datasets named XYZ. are owned by XYZ instead.  What danger?  You say you stand by your initial warnings, but your initial warnings didn't actually say anything—just "very dangerous", and I don't see where the danger lies.

It's probably not fair to say your warnings don't say anything, because you did try to say a few specific things.  But none of them strike me as reasons to fear:

"There is no verification prompt..."  Yes, TSS does what I tell it to without complaint.

"If you mistype the ADD command, you can create an owner shorter than what you intended...".  If I'm not to assign ownership because I might make a mistake, then for the same reason I should never do any security administration at all.

"Not every customer can own each TSO ID because of conflicts in other dataset names, which are already owned at a shorter length."  We've already discarded that one by using the period in the assignment.  Properly done, then, every customer can (and in my opinion should) own his own TSO datasets.  But I'm still listening, in case I'm wrong; that's why I'm asking.

"[Need for UNDERCUT] is an indication you are already conflicting with existing ownerships."  Well, no; it isn't a conflict, it resolves the conflict—which is the purpose.  Isn't it?

If you know something I'm missing, I still want to know what it is.  You just haven't said it yet.

[Robert Bridges]

Well, dang, I posted a reply a day or two ago, but after I finished my effort disappeared.  The main Discussions panel acknowledges that I answered, but counts only 3 replies and that's all I see here too.  Let's try again:

1) Right you are about two-char ownership.  Even as I typed in that one-letter DSN it looked a little off to me, not because I remembered what the manual said about it but probably because I always see two chars when I actually look in TSS.  Ok, two it is.

2) But I don't yet see the problems you're trying to describe about ownership.  Maybe I'm making it simpler than it really is.  Here's the way I see it:

a) Some time in the far-distant past, a security admin wrote "TSS ADD(DEPT99) DSN(X*)" (and likewise the other chars).

b) Now I create a new ACID and include "TSS ADD(XYZ) DSN(XYZ.) UNDERCUT"

As a result, most datasets starting with 'X' are owned by DEPT99, but datasets named XYZ.something are owned by user XYZ.  Where's the problem?  You say you stand by your initial warnings, that it's very dangerous, but as far as I can see your initial warnings don't actually say what the danger is.

"There is no verification prompt when you use the TSS ADD command."  Yes, when I issue a TSS command it does exactly what I told it to do.

"If you mistype the ADD command..."  Yes, if I make a mistake then I've introduced a mistake into TSS.  But if this is a reason not to assign ownership, it is likewise a reason not to do any security administration.

"Not every customer can own each TSO ID because of conflicts in other dataset names, which are already owned at a shorter length."  But that was based on a misunderstanding of the string I proposed using; we've disposed of this one.  The way I have it, every customer can own his own TSO datasets.

"If TSS is warning you that your ADD command will not work without an undercut, that is an indication you are already conflicting with existing ownerships."  Well, no; using UNDERCUT isn't a conflict, it resolves a conflict that would otherwise exist.

"....if you need to undercut access, you have to be scoped...."  That's not a reason not to assign ownership to each user; it means only that only properly scoped admins can do it.  I didn't mean to be unclear, but my question is about how a properly scoped admin should do things.

I'm still listening, though, because I assume you have some reason to worry about this.  Are you able to say what it is?