x-acl lightweight utility to organize Access Control List (ACL)
Greetings, habra-community!
Each project (web project) has questions about the organization of access rights. In this area there are certain ready-made tools for various frameworks Zend, Symfony, Yii, etc. Probably someone faced with something and generally imagines what it is. For those who have not encountered - I advise you to open the documentation of any of these frameworks and get acquainted. In particular, the author of the post worked very closely with Zend_Acl. But relatively recently decided to explore the issue of ACL in C ++
It all started very simply, there is a samopisny project with a good load (for ethical reasons, its name is not called, it is self-written for historical reasons, 200K unique). The project, as in most cases, "dictates the tradition" is written in php. The organization of access lists in it, as such, is absent - there are banal conditional operators in case of what “role”, what to do. These crutch solutions work in principle, but they are extremely unsatisfied. Armed with search and common sense, it was decided to create a small, lightweight c ++ utility that I would like to share with the community.
')
After analyzing in detail the zend and the ideology of access lists, it was clear that the requirements for the utility are very simple - it must get a list of rights and, depending on the situation, whether access to one or another resource is allowed, in addition, since this configuration file can edit system administrators - they should be easy to navigate what's what. From these considerations, the choice was made in the direction of the usual configuration ini file. Example:
Where [guest] is the user role, and view: news and view: comments are the corresponding resources. Many may wonder why, let's say a resource is called not comments: view, but vice versa view: comments - the answer is simple, if you conditionally divide the resources according to the CRUD database, you will understand that there are not so many options you can think of, and you can visually see the roles accordingly. to divide who is looking, who is updating, etc. Moreover, in such a format it becomes possible to do so:
Which in turn means guests are allowed to watch everything.
Simple, isn't it?
The attentive reader, obviously, has already managed to notice that in the name of the resource there is a colon character. This is a conditional mandatory separator with which you can do such things:
The utility does not impose a grouping of resources and you can group as you see fit and as best suits your project. But the presence of a colon between subgroups makes it more logical to separate the constituent parts of the resource.
Simple resolution is not interesting, obviously we can and deny access to individual resources:
By this rule we prohibited the user to view the news with ID 28
To describe the rules for each individual role is very tedious, so there is a mechanism for inheritance:
In this case, the role of user , besides its rules, will also contain rules from the role guest
An additional feature in my opinion is the ability in the configuration to describe the case when the user can edit his comments. That is, only those directly created by him. To do this, use the symbol ^
For example:
I think it is now clearer to see why the colon is used forcibly divided into subgroups, because in this case, the comment ID will be substituted for ^ .
As mentioned above, this is a utility. Accordingly, after its successful compilation can be performed in the console:
We ask whether the guest user has access to the resource view: news
We ask whether the user role has access to the edit: comment: 28 resource; if anyone has forgotten, we set the edit rule: comment: ^, - in this case, there is a ^ symbol, so the user-id and owner-id arguments are checked for equality and if they equal (and they are equal in this example) - access will be allowed.
github.com/AlexeyParhomenko/x-acl
The author is familiar with some. Create a new tool prompted:
1. Make acl more flexible for our needs;
2. Raise the profit on memory consumption, since in this case, unlike php, there is no creation of bulky Zval structures;
3. Raise profit in speed. While we are testing, but if it turns out to be a parsing config file every time, we will be able to switch to a socket solution;
Naturally.
Debian is used on our servers, as the author does in the form of a working environment, so I’ll say for sure that it works perfectly on debian. On other * nix distributions should also work stably.
Comments are very welcome, as I would like to understand how useful this tool can be in the future. Or, if I was looking badly and the already described functionality is available - send it to Google!
I will be glad to hear the errors / inaccuracies in the text or the source code in a personal, or, perhaps, any further wishes.
Each project (web project) has questions about the organization of access rights. In this area there are certain ready-made tools for various frameworks Zend, Symfony, Yii, etc. Probably someone faced with something and generally imagines what it is. For those who have not encountered - I advise you to open the documentation of any of these frameworks and get acquainted. In particular, the author of the post worked very closely with Zend_Acl. But relatively recently decided to explore the issue of ACL in C ++
So, how it all began ...
It all started very simply, there is a samopisny project with a good load (for ethical reasons, its name is not called, it is self-written for historical reasons, 200K unique). The project, as in most cases, "dictates the tradition" is written in php. The organization of access lists in it, as such, is absent - there are banal conditional operators in case of what “role”, what to do. These crutch solutions work in principle, but they are extremely unsatisfied. Armed with search and common sense, it was decided to create a small, lightweight c ++ utility that I would like to share with the community.
')
Access configuration
After analyzing in detail the zend and the ideology of access lists, it was clear that the requirements for the utility are very simple - it must get a list of rights and, depending on the situation, whether access to one or another resource is allowed, in addition, since this configuration file can edit system administrators - they should be easy to navigate what's what. From these considerations, the choice was made in the direction of the usual configuration ini file. Example:
[guest]
view:news
view:comments
Where [guest] is the user role, and view: news and view: comments are the corresponding resources. Many may wonder why, let's say a resource is called not comments: view, but vice versa view: comments - the answer is simple, if you conditionally divide the resources according to the CRUD database, you will understand that there are not so many options you can think of, and you can visually see the roles accordingly. to divide who is looking, who is updating, etc. Moreover, in such a format it becomes possible to do so:
[guest]
view:*
Which in turn means guests are allowed to watch everything.
Simple, isn't it?
The attentive reader, obviously, has already managed to notice that in the name of the resource there is a colon character. This is a conditional mandatory separator with which you can do such things:
[moderator]
edit:*:comments
#
edit:news:comments
edit:wall:comments
The utility does not impose a grouping of resources and you can group as you see fit and as best suits your project. But the presence of a colon between subgroups makes it more logical to separate the constituent parts of the resource.
Simple resolution is not interesting, obviously we can and deny access to individual resources:
[user]
view:news:28 = deny
By this rule we prohibited the user to view the news with ID 28
To describe the rules for each individual role is very tedious, so there is a mechanism for inheritance:
[user : guest]
In this case, the role of user , besides its rules, will also contain rules from the role guest
An additional feature in my opinion is the ability in the configuration to describe the case when the user can edit his comments. That is, only those directly created by him. To do this, use the symbol ^
For example:
[user]
edit:comment:^
I think it is now clearer to see why the colon is used forcibly divided into subgroups, because in this case, the comment ID will be substituted for ^ .
How it works
As mentioned above, this is a utility. Accordingly, after its successful compilation can be performed in the console:
./x-acl --config x-acl.conf --group guest --resource view:news
We ask whether the guest user has access to the resource view: news
./x-acl --config x-acl.conf --group user --resource edit:comment:28 \
--user-id 4 --owner-id 4
We ask whether the user role has access to the edit: comment: 28 resource; if anyone has forgotten, we set the edit rule: comment: ^, - in this case, there is a ^ symbol, so the user-id and owner-id arguments are checked for equality and if they equal (and they are equal in this example) - access will be allowed.
Where can I download and play
github.com/AlexeyParhomenko/x-acl
List of suspected questions :)
- Why reinvent the wheel if there are ready-made tools?
The author is familiar with some. Create a new tool prompted:
1. Make acl more flexible for our needs;
2. Raise the profit on memory consumption, since in this case, unlike php, there is no creation of bulky Zval structures;
3. Raise profit in speed. While we are testing, but if it turns out to be a parsing config file every time, we will be able to switch to a socket solution;
- Do you plan further support and fix bugs?
Naturally.
- For which OS does it work?
Debian is used on our servers, as the author does in the form of a working environment, so I’ll say for sure that it works perfectly on debian. On other * nix distributions should also work stably.
Comments are very welcome, as I would like to understand how useful this tool can be in the future. Or, if I was looking badly and the already described functionality is available - send it to Google!
I will be glad to hear the errors / inaccuracies in the text or the source code in a personal, or, perhaps, any further wishes.
Source: https://habr.com/ru/post/155099/
All Articles