When a table is fetched using the R function opal.table_get , the table is first exported to the local
file system in the RDS file format and subsequently downloaded to the local R client. The export is
triggered via an API call like the following:
POST /ws/project/ProjektA/commands/_export HTTP/2
Host: <mydatashieldhost.mydomain>
Cookie: opalsid=a4b56723-032b-465d-9eb8-e8047344gfhj
User-Agent: libcurl/7.88.1 r-curl/5.0.0 httr/1.4.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Accept: application/json
Content-Length: 217
{
"tables": [
"ProjektA.TestTableA"
],
"format": "rds",
"out": "/home/test_user1/R/7344353//file333393f81300.rds",
"nonIncremental": true,
"noVariables": false,
"copyNullValues": true,
"entityIdNames": "id"
}
we found that the server does not check the permissions on the path specified via the JSON field
out
. That means that even if the client specifies a path that they usually
are not authorized to write to, the export still succeeds and creates said file in the virtual file
system.
During our test this was used to create a file called test.rds
inside the virtual directory /home
:
However, the file is locked to the user, but I think this also could be a vulnaribility.
Thank you
Please add an issue at Issues · obiba/opal · GitHub this is the preferred channel of communication
Thank you for your reply. Issue created here:
opened 08:30AM - 05 May 23 UTC
**Describe the bug**
we are using DataSHIELD for different projects with differ… ent users and roles. We found out that when each user (even with the least permission of “View dictionary and values of all tables” inside one project) can view the name of other projects and other users as well as the tasks they have done and their logs!
**To Reproduce**
The export is triggered via an API call like the following:
```
POST /ws/project/ProjektA/commands/_export HTTP/2
Host: <mydatashieldhost.mydomain>
Cookie: opalsid=a4b56723-032b-465d-9eb8-e8047344gfhj
User-Agent: libcurl/7.88.1 r-curl/5.0.0 httr/1.4.5
Accept-Encoding: gzip, deflate
Content-Type: application/json
Accept: application/json
Content-Length: 217
{
"tables": [
"ProjektA.TestTableA"
],
"format": "rds",
"out": "/home/test_user1/R/7344353//file333393f81300.rds",
"nonIncremental": true,
"noVariables": false,
"copyNullValues": true,
"entityIdNames": "id"
}
```
**Expected behavior**
we found that the server does not check the permissions on the path specified via the JSON field out. That means that even if the client specifies a path that they usually are not authorized to write to, the export still succeeds and creates said file in the virtual file system. During our test this was used to create a file called test.rds inside the virtual directory /home
**Screenshots**

**Additional context**
Security
Authorization