There is a Moodle system with the following:
There are 20 courses a year, every course has 2 teachers. In the end of each course there is a final exam.
Right now - every teacher can see the results of all the exams.
Wanted state - every teacher can access only the results of the courses he teaches.
Is that posible?
It sounds like the teachers are getting their permissions from systemwide roles rather than course roles. Try going to Site Administration > Users > Permissions > Assign System Roles and see if there's a system role that they all have. If so, click on it and remove them from that role.
Then, add teacher permissions just for the course they teach. Enter the course and enroll the teacher, then follow the instructions in the documentation for assigning course roles. This may cause them to have both a student and a teacher role, but that's not a problem; the system will treat them as a teacher.
Related
I am new to Postgres, sorry if the question is basic:)
I need to create a personalized role for any customer already existing in the DB.
Role name must be client_{first_name}_{last_name} (without curly brackets).
Also, this customer can only access his own data in "table_1" and "table_2" tables.
I took ALICE STEWART (id 51).
What I did:
I created role Customer with Select privilege. Then tried to create role for ALICE STEWART and I get an infinite recursion error.
But how to create role for one customer so that he could access only his info in 2 tables?
How to do that properly?
There is nothing wrong with personalized database users, but I would only consider that if you don't have very many users. I wouldn't want to deal with a pg_authid that contains 100000 users.
I would not play this with permissions, but with row level security. The exact way in which that would work depends on your data. The easiest way is to have and owner column that lists the user that can see the data.
Watch out for overly complicated policies, as they will make your queries slow.
I am working on designing role based access for an application. Here, there are various department like HR, Finance , Developer ,etc. I am planning to have department level accesses on their respective related table like Finance user can access Payroll table...
I have done some R&D and came up with following approach.
Currently I have thought to have Department level user roles.
I have planned 3 roles Viz. super admin ,admin & user. So lets suppose if HR user makes a request to write data on employee we can check if user is from HR and then we grant this access.
Problem is that I am not able to design how to place an access table which can have collection of all accesses like employee_read_write or payroll_read_write ,etc.
Should I be creating a new access & map it somehow to user roles & department OR map the different tables that can be accessed on department level like Finance department has payroll accesses.
Since, I am new to RBAC kindly let me know if this is the right approach that I am planning or there is some better way. Appreciate your inputs !!
So I am using Node/MongoDB (mongoose) to implement this feature.
What I need is the right solution for the following problem:
We have many Company(ies)
Each Company can create it's own Roles
Role is a set of predefined Permissions (like task.create, task.read, task.update, task.delete)
They can choose which Permissions are included in which Role
Company can create it's own Users, and assign them a Role
Lets say that company created 3 roles (the order matters):
Owner (always predefined, has all Permissions)
Team Leader
SuperAgent
Agent
Beside that, I also have Users in a tree structure, with parent reference which holds the _id of the User above him.
The rules are:
User can have none or many children
User cannot be above someone that have higher role than him
User cannot be below someone that have lower role than him
The Tree can get as deep as they want...
So the right representation of this would be:
But because Company Owner can at any time make new Role, or switch the order of roles, the problem occurs...
Let's say he switched the places of 2 roles, and they are now:
Agent
SuperAgent
How would you update all Users?
Also, what if he creates a new Role, puts it in 3rd place, and now needs to update everyone 1 role below, so he can attach that new role to a user...
What approach would you take to solve this kind of issue?
From the PostgreSQL docs:
The concept of roles subsumes the concepts of "users" and "groups". In
PostgreSQL versions before 8.1, users and groups were distinct kinds
of entities, but now there are only roles. Any role can act as a user,
a group, or both.
Why did they make this change in 8.1?
Perhaps it's easier from the C coders point of view, with a single Role class (struct)?
More details:
CREATE USER is equivalent to CREATE ROLE except that CREATE USER gives the LOGIN permission to the user/role.
(I'm about to design a permission system for my webapp, hence I'm interested in this.)
The merge has many advantages and no disadvantages. For instance, you can now seamlessly convert a "user" to a "group" and vice versa by adding / removing the LOGIN privilege.
ALTER ROLE myrole LOGIN;
ALTER ROLE myrole NOLOGIN;
Or you can GRANT membership in any other login ("user") or non-login role ("group") to a role:
GRANT joe TO sue;
You can still:
CREATE USER james;
That's just a role with login privilege now. Or:
CREATE GROUP workers;
That's effectively the same as CREATE ROLE now.
The manual has it all.
I found this thread in the PostgreSQL-Hackers list, from June 6, 2003, that in the end suggests that users and groups and roles be consolidated. (Thanks Craig Ringer for suggesting that I check the pgsql-hackers list archives.)
Here are some benefits mentioned (those that I found).
allow groups to have groups as members
the ACL code would be simplified
the GRANT/REVOKE syntax and the display format for ACL lists could be
simplified, since there'd be no need for a syntactic marker as to
whether a given name is a user or a group.
In some circumstances I could see it making sense to allow logging in
directly as a group/role/whatchacallit
This would also solve the problem that information_schema views will
show only owned objects
[makes it easier to] representing privileges granted to groups [since
you'd simply reuse the role related code?]
From the manual:
The SQL standard defines the concepts of users and roles, but it
regards them as distinct concepts and leaves all commands defining
users to be specified by each database implementation. In PostgreSQL
we have chosen to unify users and roles into a single kind of entity.
Roles therefore have many more optional attributes than they do in the
standard.
Having a distinction between users and groups doesn't gain you anything.
AFAIK the motivation for changing it was to simplify uses like:
One user masquerading as another, eg a superuser simulating a reduced permissions user. With unified roles this becomes just another change of current role, no different to changing primary group.
Groups that are members of other groups to implement granular access permissions.
If you want the details, though, you're best off checking out the archives of the pgsql-hackers list for the period, and the git history (converted from CVS).
What is the differences beween roles and users.
A role can have many users. An example might be an Admin role, which could mean someone who's assigned and their backup. Both would have the same rights, which are embodied in the role. Individuals can come and go, but roles remain.
A role typically defines a business function (or set of functions) performed by one or more users. Examples would be 'customer service agent' or 'business analyst'. A user is an individual person who is included in the role - Bob, Nancy, and Steve might be assigned to the customer service agent role.
This makes is easier to assign permissions to database objects. You can assign permissions to the role, and any user who belongs to that role inherits the same set of permissions.
On a technical level, see other answers. On a practical level, when you have large user set with fluid permissioning needs due to changing roles, the difference is that assigning per-user permissions means any change in user responsibilities necessitates permissions changes on MULTIPLE database objects that user needs to be added to/removed from perms.
Whereas if the perms are assigned to the roles, the only change is in the role membership.
The latter is both significantly less resource taxing on DBAs, and due to less work needed, significantly less likely to suffer from operator error (e.g. less work to do => less chance to screw it up) and thus more secure.