Play with Permissions

(Ref Id: 1436717593)

When building your DIY LIMS solution you might come across permissions. That is, some data should not be viewable or editable by all users; and some processes should not be executable by everyone. A popular method is to simply divide the system into two parts -- one for individuals with 'administrative' access and another for everybody else. Master, or setup data, along with certain processes can only be accessed by individuals with administrative rights. In some cases, particularly with smaller labs, this is the right way to go. No complex permission model becomes necessary as you would only need to ensure that administrators have the correct training.

But what if we wanted to explore doing more with privileges of this sort? Do we recode our system? Perhaps we can use a Linux terminal window instead.

Example:

cd /tmp
touch myfile.txt
ls -l myfile.txt

Reveals (note, your results might be different depending on your settings):

-rw-r--r-- 1 limsexpert limsexpert 0 Jul  5 22:23 myfile.txt

We are looking at file permissions -- those symbols at the beginning of the line. They are presently set to the following:

If someone is a member of the specified group (the group is the fourth item from the left on the line) they can read the file. Everyone other than the owner can read this file but will be unable to write to it.

Permissions for files are a lot like record settings in a database that we would want to use for a LIMS. At a very basic level we want to know whether the current user can view (read), or update (write) the contents of a file. What is missing, that we will need as well, are two additional controls -- the ability to create and the ability to delete a record (special note: in a LIMS we avoid deleting anything so here 'delete' really means to archive the record in some way). In Linux these are controlled by your access rights to the containing folder.

Create and Delete

Let's imagine that a record in our system has the two additional permissions that we described earlier -- create and delete. For completeness we'll change our read and write flags to 'R' and 'U' respectively and use 'C' for create and 'D' for delete privileges.

Owner  Group  Everyone
---- ----- --------
CRUD RU R

So above the owner of the file can do anything with it; a group member can read and update it only (this makes more sense in a LIMS); and everyone else can simply read the entity (this makes no sense in a LIMS as we will see in a minute).

What to Remove

In a LIMS we normally want to avoid the the concept of a record owner. With the possible exception of some user-specific information (favorites, most recently used identities, etc.) almost all records in the system should belong to groups. Also, there really isn't anything in the system that 'everyone' can do or see except the login screen. Everyone with access should be a registered user of the system or they get nothing. So we can simplify our model to:

Admin  Group (LAB)
----- -----
CRUD RU

Members of the administrative group can do anything with the record and members of the assigned group (the LAB group) can read and update the record only.

Let's look our our new description of the record now:

-CRUD-RU- 1 limsexpert 0 Jul  5 22:23 myfile.txt

Additionally, since we know that an administrator will always have the ability to fully access to the record, we can shorten it some more:

--RU- 1 limsexpert 0 Jul  5 22:23 myfile.txt
Roles

Roles can be explained by using our friendly Linux shell again:

cd /tmp
echo echo $(date) > ascript.sh
cat ascript.sh
chmod 755 ./ascript.sh
./ascript.sh

Here we created a silly script that echoes a date string and then changed the file's permissions so that it is now executable:

-rwxr-xr-x 1 limsexpert limsexpert 33 Jul  5 23:15 ascript.sh

What if we had executable permissions on a file but not the read permission...could we see its output? Let's see:

chmod uog-r ./ascript.sh
./ascript.sh
/bin/bash: ./ascript.sh: Permission denied

Change it so that the owner can read it:

chmod u+r 
./ascript.sh

Now it works. Consequently, the read permission for executables also controls whether you can see the script's contents:

chmod uog-r ./ascript.sh
cat ./ascript.sh

If we take away the read permissions and try to view the file's contents we get a permissions error. So you can see that executable code's 'R' flag really stands for two permissions -- one that says you are allowed to see the code itself and another that says you are allowed to read the output of the process.

If we took away file ownership and the concept of 'everyone' in Linux it would be a combination of group membership and the executable settings on files themselves alone that would determine whether a particular script could be run. In a LIMS it makes more sense to segregate groups that pertain to data ownership from those that control the ability to execute code. We call the latter 'roles' are they are only assigned to executable scripts.

So for example a record would belong to the RAW_MATERIALS group but the LAB_ADMINISTRATOR role would be able to execute different scripts than the USER role. If we moved our individual file create/read/update/delete actions into scripts then we could assign roles to them, making it possible to assign the 'create', 'read', and 'update' scripts to the USER role for a particular table but not the 'delete' script. We could also give the ability to see/modify the script contents to another role -- the DEVELOPER role.

Summary

So now you have a primer on groups and roles along with practical examples that you can try out provided you have a copy of Linux/Unix lying around or at least some shell access to such a system. Try to emulate what a LIMS does purely using groups. That is, assign certain groups purely to execute scripts with a 'ROLE_' prefix. Make scripts for create/read/update/delete that take folder names as parameters. See what happens.

The freely available Linux operating system can become a fertile ground for experiments like these outside of the confines of an existing LIMS because of its universality. You can use it to exemplify a problem or test out some scenarios in file permissions without too much effort.

Go Back

Citation: Play with Permissions. (2015). Retrieved Fri Jun 23 02:53:21 2017, from http://www.limsexpert.com/cgi-bin/bixchange/bixchange.cgi?pom=limsexpert3;iid=readMore;go=1436717593