SAP Directories - AL11 - S_DATASET

[Former Member]

Hi All,

There are two Roles say ZXX and ZYY which are present in all the jobs in a Development system.

Both the roles have authorization object S_DATASET where FILENAME field is unrestricted.

The Transaction AL11 present in some role say ZAA where the authorization object S_DATASET is restricted to certain files under the FILENAME field.

Since the users are assigned with the jobs which includes role ZXX and ZYY,they are getting display access to ALL SAP Directories, regardless of the single role ZAA has S_DATASET restricted.

Please provide a way to restrict users to see particular path files only.

Thanks & Regards,

Gopi Lakshmipathy.

[Former Member]

Gopi,

the roles - ZXX and ZYY are not restricted and they have access to all the files / dataset under S_DATASET?

If that is the case then this needs to be restricted. AL11 just gives you the list of all the SAP directories and is no way related to give access to the files and folders - this access is only controlled by S_DATASET.

Thanks

Khan

[Former Member]

The file name is also not of much use if you do not know it's name.

Generally, the program will know it's name, so restricting the program field of S_DATASET (and protecting variants in VARCH...) will make more sense.

If you want to protect the directory path to the file, then you need to use the protective authorization group concept of object S_PATH.

Take a read through function module AUTHORITY_CHECK_DATASET and search the forum here for discussions about it. "SPTH" is a good search term.

Cheers,

Julius

PS: Someone asked me an interesting question recently about this: As the directory paths will change between DEV, QAS, PROD... how do we develop roles for S_DATASET and S_PATH and transport them without changing them in the target systems? Org levels for server names seemed to be an option, but it seemed a bit odd to create... Any other ideas? (or should I open my own thread

Edited by: Julius Bussche on May 4, 2009 11:05 PM

[Bernhard_SAP]

Hi Julius,

a good possibility would be the availability of variables for FILENAME, PATH,...

Unfortunately this is not available in stnadard until now....

The generation of authorizations (in pfcg) is not able to resolve variables, and

also the kernel cannot interpret variables.

So both possibilities (replace the used variable at profile generation or let the Kernel replace a used variable) are not available. Furthermore it is also not planned to implement this possibility in standard

In SAP note #177702 I have found an interesting paragraph:

....

S_DATASET is delivered by default with PROGRAM = *, ACTVT = * and

FILENAME = *.

On Unix, you can create links as a workaround, that correspond to these

restrictions and that refer to actual files.

......

So propably if you are running your system on Unix there is a way to resolve variables on OS-level????

I am coming from the mouse-click-fraction, therefore I don't know the unix capabilities...

b.rgds,

Bernhard

[sdipanjan]

To Gopi: Deactivate S_DATASET in ZXX & ZYY.

>

> PS: Someone asked me an interesting question recently about this: As the directory paths will change between DEV, QAS, PROD... how do we develop roles for S_DATASET and S_PATH and transport them without changing them in the target systems? Org levels for server names seemed to be an option, but it seemed a bit odd to create... Any other ideas? (or should I open my own thread

>

> Edited by: Julius Bussche on May 4, 2009 11:05 PM

To Julius: I am not sure, but did you try with "Wildcards"?

for e.g.: If the SIDs are like below:

DEV : RD1

QAS: RQ1

PROD: RP1

Then for FILENAME, we can use like this:

/oracle/<SID>/export_dir/dataload/labels/... this can be written as: /oracle/R?1/export_dir/dataload/labels/...

If my intention is to restrict specific group of users to restrict them view only the directory for Oracle (for e.g.), then I can do this like this also: /oracle/* and it works. I used this before. You don't need to bother about the SID which is different for this string (representing a path/directory) in different systems.

Regards,

Dipanjan

[Former Member]

@ Julius - Nice question

Also, this includes the challenge of restricting files on windows having a path greater than 40 characters.

Maybe a security wishlist

@ Bernhard - We had faced this challenge of restricting files having long path names on windows OS.

We tried everything possible, logical names using FILE, variables ..nothing worked. We also tried creating variable at OS level.. that too didn't work

For UNIX, since this is a file system, we can mount directories....hence creating a shorter logical path on the OS level.

@ Dipanjan - '?' does not work either. Just '*'.

Regards

Abhishek

[Former Member]

> Also, this includes the challenge of restricting files on windows having a path greater than 40 characters.

You might also want to consider that the ability to maintain 40 characters in a PFCG field does not necessarily mean that the authority-check for all OS's have that ability to read all of it.

There are a few object fields which are truncated at the 18th character... (depending on the release you are on).

In addition to naming conventions being important... (which is a good idea anyway and logical consequence of constraints) I personally think that the path hook of authorization S_PATH is the solution for protecting paths and the file name is not particularly usefull, even if it does look like a "path".

This (table SPTH) is also subject to configuration, so the possibility exists to do some "soft config" in QAS and PROD without disturbing the consistency of the roles maintained in DEV.

=> Even although the auth groups have the same name in the role, they point to different directory paths.

This is a tricky thing to implement, but in my opinion the best possible way if you want to use granular security at this level.

Cheers,

Julius

[Former Member]

Hmm....didn't have an idea on the OS, thought this was a limitation of windows, unlike UNIX where mounting file systems is an option. Agree with you that a good directory path is always an appropriate method..and that's what we are working on right now.

To add to our woes, this field is case sensitive...and we had to fix a naming convention for that too. so that the role value matched the OS path.

Never worked too much on S_PATH.

Coming back to your question of implementing this in a landscape... we are also facing the same problem. One idea we had was to have add-on roles per system. Adding this add-on role in addition to give access to the directory per system.... never really drilled down on it. It has program restrictions too which also need to be thought about.

Thanks

Abhishek

[Former Member]

Looking at roles and auth concepts in systems, this level of granularily is hard to achieve using the filename...

That is why the optional S_PATH object is in my opinion more suited for "protection" as an option.

If data is worth protecting, then it is better to proect it at it's source.

At the application layer, you can use S_DATASET to restrict the program names.

I would concentrate on the program name and the path for a concept, and not the file name field.

Cheers,

Julius

[andreas_noack]

Hi Julius,

a long time ist gone since your question:

PS: Someone asked me an interesting question recently about this: As the directory paths will change between DEV, QAS, PROD... how do we develop roles for S_DATASET and S_PATH and transport them without changing them in the target systems? Org levels for server names seemed to be an option, but it seemed a bit odd to create... Any other ideas? (or should I open my own thread

Now I'am facing exactly this problem; and my opion is that either S_DATASET nor S_PATH will help me to solve the problem of changing path names between the systems of a landscape.

Is there any new solution which you can provide?

Cheers

Andreas

Edited by: Andreas Noack on Dec 7, 2011 7:15 PM

[Former Member]

There are at least 3 options for you (that should however not make it sound easy...

1) It makes sense for a number of cases to have the same users equiped with different roles in DEV, QAS and PRD (for example developers, support, security admins, etc). In this cases you could use different roles for these users, as well as batch and RFC users and test users who have different S_PATH authorizations in the systems. This either means parrallel maintenance of the roles and a naming convention which includes "DQP" to identify it, or to carve out the S_PATH object into a "delta role" which is assigned system specific. This assumes consistent S_PATH entries.

2) Drop the assumption of consistent S_PATH entries in table SPTH, and you can use the authorization groupings of the paths "system specifically" and keep the authorization groups for the paths the same in the roles. It might make sense to mimic a "Deny everything else" entry by using a blacklist auth group for asterisk paths, but that means that you have found and authorized all which you want to "permit" in the table. Actually I am not sure whether this would infact work or be practicable.

3) Switch to transaction FILE. Concentrate in the S_DATASET authorization to restrict the Program name and ACTVT the user has access to. Make sure that the program does not allow the file path / name as input parameter but rather the "logical file name" of those in transaction FILE. Ideally they should even pick up the logical file name from config and not the user input anyway.

Go for # 3 would be my advise... however once transactions such as CG3Y etc are out of the bag, then the program restriction does not help much anymore if you relaxed the file name in S_DATASET. Considering that there are about 3 million programs in a SAP system, granting explicit program contexts and knowing what they do to the file system is the safest and easiest option, as you typically only need a handfull of them.

Has anyone else faced this? Any other solutions been tried?

Cheers,

Julius

[andreas_noack]

Thank you Julius for this promt answer.

To look for a solution based on the capabilities of the authorization managment. In the moment I think all the discussed possibilities like S_PATH and FILE can not been used by the authorization management itself. S_PATH and FILE and as well the kind of development of programs need to have more involvement of all parties in a company.

In the moment we do have a role with S_DATASET that looks like:

S_DATASET (1)

ACTVT = 33, 34

PROGRAM = /CCC/PROGRAM-NAME

FILENAME = /WORK/SID-TEST/FILENAME

S_DATASET (2)

ACTVT = 33, 34

PROGRAM = /CCC/PROGRAM-NAME

FILENAME = /WORK/SID-QUALITY/FILENAME

S_DATASET (3)

ACTVT = 33, 34

PROGRAM = /CCC/PROGRAM-NAME

FILENAME = /WORK/SID-PROD/FILENAME

In the eyes of the auditors they see the risk, that in this combination a user of the programm "/CCC/PROGRAM-NAME" in the Quality-System can use data from the Productiv-System, as he has access to "/WORK/SID-PROD/FILENAME" too.

My idea is to bring S_DATASET in 3 different "add-on"-roles with different FILENAME which differs in "/SID-xxxxx/".

This leads to the challenge to maintain existing roles, existing users and implement a change process in the Access Process, as in the moment it is easy to grant the same role in the hole system landscape. This has to be enhanced to grant the exact add-on role per SID-xxxxx.

I would be peased to achieve more advice

Andreas

[Former Member]

Yes, in this case the temptation to create a system specific attribute to the role and carve S_DATASET and S_PATH out of the other roles is almost irrresistable...

However, if this is only for a specific solution (program name) then what about all the other roles? If it is for all the roles requiring S_DATASET then how many "delta roles" are you going to end up with?

Prerequisite is that you have maintained explicit program-names in all the S_DATASET authorizations of all the roles so that you are able to isolate this /CCC/* program context here without the others overriding it.

That can only be done by maintaining SU24 and getting everyone (including particularly the developers) to play along with it. There is no other sustainable way IMO.

See [How to get hit by the ABAP authorizations bus, and survive to tell the tale - Part 2|http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/11687] [original link is broken] [original link is broken]; which deals with exactly this example.

Cheers,

Julius