Pre-Assigned Library Authorization doesn't set correctly

[char22]

Hi,

I am set library properties to pre assigned type By metadata library engine

At the authorization , I set the user to read and read metadata only, so it should be error when I am trying to export and delete data in it.

Instead of error, it delete and write executed successfully.

I wonder, what setting need to be set?

Regards,

Charlie

[LinusH]

Trouble shoot authorization over the community is usually hard.

In what tool do you succeed with delete/write?

If in EG/Base SAS issue

a

libname yourlib list;

to verify that your assignment setting is in effect.

If as you expect, you need to track your metasuser and table object authorization settings. See Intelligent Platform doc for help.

Also, there is a tool from Metacoda (plugin to SMC) that I think helps you with tasks like this.

[char22]

Hi Linus,

It's SAS EG application

Running libname code will grant the user to all permission

libname yourlib list;

I have tried read only properties set in the library, It work, but this case, I need to set some group to read write delete, while others are read only

Regards,

Charlie

[LinusH]

Running

libname yourlib list;

will display libref settings, not grant any new/different access.

I think that there's a capability that can prevent users to assign their own librefs.

If you really want to secure your Base library data, take a look at Meta Bound Libraries. 

[anja]

Hi,

are you programmatically creating libraries or through SAS Management Console?

Thanks

Anja

[char22]

Hi Linus,

Sorry , my mistake.

Already check the libname list command, it run just fine.

Already tried the metadata bound library. Looks like it works perfectly, deny create table will prevent some groups from create table in the library

But I wonder, why pre assign with metadata engine doesn't prevent user from writing the library(isn't deny access WriteMetadata will prevent user from creating table in the library?)

Hi anja,

I create the library through management console

Regards,

Charlie

[anja]

Hi char22,

Are you trying to go by the "lockdown" as described in the sec admin guide?

Lets take the pre-assignment out of the picture for a moment, and please correct me if I misunderstood:

You have several groups.

Some of these groups are allowed to read/write/delete metadata, while others are not allowed to delete.

Is the problem that the same users are in different groups, allowed to delete/read/write with one group, but

not with the other?

(I am trying to find out if the issue might be due to conflicting permissions).

Or,

is the problem that you simply have different groups, with different permissions, where some groups can and some

cannot delete?

Next:

Please provide an example where you describe exactly how the security set up is supposed to be.

Such as:

data A

Group A deny for delete/wm/rm

Group B grant  for ...

this is the behavior: ...

Does that make sense, do you know where I am getting at with this?

Thanks

Anja

[char22]

Hi Anja,

Haven't tried the lockdown, is it needed?

Let say I have Library Lib

Group A , Group B, Group C

Group A permission to Lib : All permission

Group B permission to Lib : Read and Read Metadata

Group C permission to Lib : Read and Read Metadata

Public permissions are deny all

SASUSERS permissions are deny all

The goal are , only Group A can write delete read, while others are read only.

Problem is All group can Write delete read.

Additional Info : I set Extended Attributes : AssignMode = 2 and pre assign lib, so the users can access the lib without hassle (assigning the library first before code or using the table are hassle). Is pre assign lib are bypassing the metadata security?

I set AD to login to metadata server , I set SAS token authentication for the login to workspace server with single user : sassrv(not sure if it is the cause)

Thanks,

Charlie

[JuanS_OCS]

Hello @char22,

I must say, you have got great directins by @anja and @LinusH.

There are some variables to take in account. 

• One is the metadata authorizations, which normally should be enough.
  • And, of course, you need to keep in mind the metadata authorizations (read metadata, write metadata) and the actual access to the data (read, write, delete, etc). From this point of view, you could grant the groups B/C/* Read metadata and Read. And the group A, additinals Write and Delete (optionally also Write Metadata).
  • Once you set the permission on the library, I would check if all the tables registered on the library are on the same folder than the library... because other folders will require similar permissions.
• Something else, besides your metadata settings, You can ensure the grants/denials on the data origin itself (file system, database, etc).
• Last remark: probably your users connect with EG or a similar way. This consideration comes from the fact that, even if you set a library as metadata initialized, if afterwards there is a second initialization (let's say, autoexec or user code), the second initialization (and it's permissions, probably none, only what is on the data origin) will take precedence and will overwrite the metadata initialization.... unless we speak about metadata-bound libraries.

So, in short, once you ensure your metadata permissions, probably you would like to ensure security on the data origin (to prevent situations as mentioned above), and check if the tables are registered on different folder and inheriting the permission you set on the library.

Best,

Juan