nextcloud / nextcloud/files_accesscontrol

Flow ACL, bug and feature requests.

Open
#200 4 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

enhancement
Dominant language
PHP
Stars
60
Forks
22
Avg merge
2d 11h
Merged PRs (30d)
34

Description

Hello,

I am playing around with the "Flow" app now and I wonder if I just cannot figure out some settings or if it is worth to request a new feature.

Short summary of bugs:
  • In flow “Block access to a file”
    • The rule: when (file accessed) and (user group membership is not member of groupx) and (file system tag is tagged with groupx)and (user group membership is not member of “admin”)-> block access -> this allows access to the folder for both groups (groupx and admin) even if this should not be the case, secondly the group “admin” is removed from the text field after saving (this works only for admin group)
Short summary of wishes, if I had some :)
  • In flow “Block access to a file”: connect logic blocks (input variables) freely with “and/or” instead of only fixed “and”
    • Make rulesets more lucid, easy to read and set maybe with simplified code like structure e.g. if(cond1=x && cond2=y){block access/allow access/permissions} ->possibility for nested conditions and use of placeholders like $usergroup or so
    • Allow rules that can set extended permissions to files and folders, like allow/deny to view/create/change/delete/share…
  • A Flow to automatically create (invisible) Tag and autotag all folders (in a certain location with a certain recursive depth) with certain name whenever a group is created.
  • Allow sorting of users/groups, make overview page for users more lucid (maybe different types of views possible?)
  • Add Tag settings (or just a link) to usersettings to have ACL things in one place
  • Add possibility to create (relative) links to other folders in NC
Long Explanation and use cases

The scenario is you want to create a group folder with several subfolders and permissions based on groups/users and tagging files/folders.

  • The first question is security related. Is it preferable to create a “group folder” as admin and share this to a group or is it wiser to create a “normal” or even guest user with limited permissions who shares with a group in terms of possible permission escalation?

Lets assume the following folder structure:

-“group-folder”
  --“group1”
      ---“project_a”
      ---“project_b”
      …
  --“group2”
      ---“project_a”
      ---“project_b”
      …
  --“group3”
      …
  --“groupprojects”
      ---“gproject_a”
      ---“gproject_b”
      …

The groups “group1”-“group3” and invisible tags with the same name are created and latter assigned to the according folder. With the flow “Block access to a file”, it can now be achieved that each group can only enter their folder inside the global/main “group-folder” by applying a ruleset like: when file accessed and user group membership is not member of groupx and file system tag is tagged with groupx-> block access.

If I add additional and user group membership is not member of admin (enter admin manually, since “admin” group doesn’t show up) both groups “admin” and “groupx” have now access but after reopening the menu the admin was removed from the text field. This is strange and I guess a failure, since all fields are connected with “and” and should therefore only work for users who are member of both groups!

However, if a folder should be accessed by two groups I’m stuck. Let’s say the subfolder “gproject_a” should be accessed by “group2” and “group3” users. I would apply both tags, but how to set the permissions in flow than, since I can only combine fields with “and” and for normal users it works like it should and denies access for users who are member of only one group.

  • If a subfolder inside a “protected” (by tags and flow) folder is shared, an error message is shown in the browser with “operation is forbidden” but after reloading the page it is shared. No msg is produced in the log file.

Another nice feature would be to be able to create links pointing to a folder or file. Right now I place links into the “readme.md” of a folder to open other related locations. Example I want to create a link from “gproject_a” in the folders of "group2" and "group3". However, relative links would do the thing already and eliminate the problem of different ways of access.

Am I missing something or how could a more complex ACL based folder structure be set in Nextcloud? Using shares only to do so doesn't do the thing, since every user will have different and wild folder structure depending on the shares instead of a common structure with set permissions for everybody.

Here are my actual system details:

short overview from “settings->support->system report”:

Server Config:
Operating system: Linux 4.15.0-109-generic # 110-Ubuntu SMP Tue Jun 23 02:39:32 UTC 2020 x86_64
Webserver: nginx/1.19.0 (fpm-fcgi)
Database: mysql 10.2.14
PHP version: 7.4.8
Nextcloud version: 19.0.0 - 19.0.0.12
Analytics 2.4.1
FileAccessControl 1.9.0
FilesAutomatedTagging 1.9.0
WorkflowExternalScripts 1.4.0
..

Thanks everybody and have a nice day

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start with the Flow “Block access to a file” interface and reproduce the reported rule-saving and access behavior using the described group and tag setup. Review the issue’s separate ACL, sharing, tagging, sorting, and relative-link requests before choosing a narrowly scoped change; done would require a defined scope, reproducible behavior, and corresponding validation.

Written by the indexing model from the issue text.

Assessment

Tech stack
php
Domain
authorization, security
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
18/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.