Libname - User should only be able to write but not deleting from it.

[SasStatistics]

If we write access = readonly in a libname statement [libname "example_libname" access = readonly; ] , then the user will not be able to update information or write new information. Source: https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/engsas7bdat/n0lzaa7wlugfn8n14wb6p4615nvg.htm 

My question is, can we set a option that makes it possible to write (add rows) to a libname but not chaning existing information/rows, e.g. deleting or chaning the information? 

[LinusH]

Not exactly the way describe it (as I am aware of).

You can get a little more fine grained control if you use the metadata library engine (MLE).

However, this gives you control over Read, Write (which inludes update...) and Delete.

So maybe you need to build some application logic (insert new rows in a separate table, and then merge with original data - not allowing any duplicates), or move the data to a external data source that supports your desired permission pattern.

[mkeintz]

As a workaround, you could maintain two libraries, one with the read-only attribute, and the other permitting appending/writing, and containing identically named datasets.  It might be common that the writeable datasets have zero observations, but the same complement of variables, as the identically named readable datasets.

The you could do all your appending to the datasets in the writeable directory.

And when you want to run a proc against all the data, you could use a view that reads in the identically named datasets from both directories.  This means you would have to define a view for each readable/writeable pair of data set files.  It probably could be macro-ized to minimize the coding needed.  

[Quentin]

Is your data a SAS dataset or is it in a database?  If it's a database (or similar), it's possible that the database would allow that sort of granular permission.  That might be your best hope. 

[Patrick]

With SAS files the real security must be applied on OS level. What would restrict a user to issue another libname statement pointing to the same folder but without access=readonly.

If you need such protection and granularity then consider using a database. That's what databases are good at.

There might be some ways with SAS tables where you get closer to what you want but it all will be "complicated" and then still not 100% what you need. 

After a "quick Google" it appears that depending on your environment there might be options how you could restrict write access to SAS files (.sas7bdat files) to INSERT only on the OS level - one discussion here.

[Ksharp]

I am not sure if "Creating and Using Integrity Constraints in a Table" could help you ,
but deserve to take a look.

https://documentation.sas.com/doc/en/pgmsascdc/9.4_3.5/sqlproc/n00g6gfl7c53ukn1qcmku5cr79r6.htm

[AllanBowe · Accepted solution]

You can get this functionality by using POST EDIT HOOKS in Data Controller for SAS (disclaimer - we built the tool).

It will soon be available natively once we finish the Column Level Security feature:  https://docs.datacontroller.io/column-level-security/

It's free for 5 users and I'd be happy to help you set it up.

https://datacontroller.io

[Patrick]

@AllanBowe What prevents a users to just issue their own libname statement?

[AllanBowe]

@Patrick  - great question.

With Data Controller you set the OS permissions so that nobody can modify the source tables.

Just the `sassrv` (or equivalent) account behind the STP server context.  There is a similar batch account for Viya (shared compute) and SASjs Server.

This way you have complete control over who can edit which tables, and even which rows within a table - see: https://docs.datacontroller.io/row-level-security/