How to only first superAdmin access to a group permissions example(signature permissions), but other admin and superAdmin no access to that (signature permissions)
for example, first SuperAdmin with id = 1 only see and access some permissions and can change it,
and other superAdmin cannot see this permission.
Super admins are defined in the library/config.php file:
$config['superAdmins'] = '1,2,3';
1, 2 and 3 being three different user IDs.
Related
I would like to configure PhpMyAdmin to access only one database through one user.
I tried before to restrict access via .htaccess using this answer from 2013 but it did not work:
phpMyAdmin Block Access to Single Database
I hence tried by adding deny,allow rules as stated in this answer:
How do I restrict access to specific database user accounts in phpMyAdmin?
But it did not work too. I continue to access all users. I have read the documentation and rewrote the lines in config.inc.php as
$cfg['Servers'][$i]['AllowDeny']['order'] = 'deny,allow';
$cfg['Servers'][$i]['AllowDeny']['rules'] = array(
'deny root from all',
'deny user1 from all',
'deny user2 from all',
'allow user3 from all',
);
where user1 and user2 are users to deny, and user2 is user to allow. But I can still access with all users. I hence tried only
$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';
that should block access to all users, but I can still access with all users. I hence believe that /etc/phpmyadmin/config.inc.php is being overwritten in some way, since no change has effect, but I do not understand how.
Any idea on where to check?
Looks like you are allowing access to all users and then again you are trying to restrict some of the users, seems bit confusing.
$cfg['Servers'][$i]['AllowDeny']['order'] = 'deny,allow';
The correct pattern should be deny access to all users and then provide explicit access to the specific user
$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';
Please refer the official document
https://docs.phpmyadmin.net/en/latest/config.html#cfg_Servers_AllowDeny_order
The correct configuration should be something like this
$cfg['Servers'][$i]['AllowDeny']['order'] = 'explicit';
$cfg['Servers'][$i]['AllowDeny']['rules'] = [
'allow user3 from all'
];
hope it works for you!
I'm using restheart 6, with mongoAclAuthorizer and mongoRealmAuthenticator.
I have no problem managing users or databases, but I'm not understanding how to restrict a user to access only the databases I allow.
I'm reading the documentation (https://restheart.org/docs/security/authorization/) about ACL, but I didn't find what I need.
By looking at the examples, looks like a user from the role "users" would be able to access all databases.
I guess the answer is in the predicate.
Let's say I have two users: userA and userB both with the role "user". I want userA to access database1 and userB to access database2.
The way the doc shows, looks like it's missing something that I wrote in brackets, which I know it doesn't exists, it is only to exemplify) ([user=userA] and [user=userB]).
role: user
predicate: [user=userA] and path-prefix[path="/database1"] and method[value="GET"]
role: user
predicate: [user=userB] and path-prefix[path="/database2"] and method[value="GET"]
Can anyone help me?
It's easier than it looks.
The roles "admin" and "user" are not mandatory.
You can create your own roles and use them as needed.
In my case above, I created four new roles: role-database1-rw, role-database1-ro, role-database2-rw and role-database2-ro.
And I've attached the userA to the roles role-database1-rw and role-database2-ro, and the userB to to the roles role-database1-ro and role-database2-rw.
Then, I created the ACLs:
roles: role-database1-rw
predicate: "path-prefix[/database1] and (method[GET] or method[POST] or method[PUT] or method[DELETE])"
roles: role-database1-ro
predicate": "path-prefix[/database1] and method[GET]"
roles: role-database2-rw
predicate: "path-prefix[/database2] and (method[GET] or method[POST] or method[PUT] or method[DELETE])"
roles: role-database2-ro
predicate: "path-prefix[/database2] and method[GET]"
This way, the userA can read from database1 and 2 and write on database1. And the userB can read from database1 and 2 and write on database2.
Is it possible in Rundeck to limit a user group to only see a specific group inside of a project. The project has 5 different groups "folders" with jobs in there. I can limit run access to the group I want, but I don't want the user group to see any of the other folders under the project. Does that make sense?
Project
group1 Hide for a user group
group2 Access for all
group3 Hide for a user group
There is.
Just remove read from the job group acl.
The follow acl only allow user from user_group to run and read jobs under group2 only. The users can not read(see) jobs other than jobs under group2
description: Limited user access for group in a project
context:
project: 'project1'
for:
job:
- equals:
group: 'group2'
allow: [run,read]
by:
group: [user_group]
Note: if you have multiple acl, your acl may be overridden by another acl file.
Rundeck ACL
I am trying to restrict edit functionality for the group 'test' but unable to do so. Below are the changes I made so far:
$wgGroupPermissions['test']['read'] = true;
$wgGroupPermissions['test']['edit'] = false;
The problem is, that you create a new group and you want to revoke a permission for this group. $wgGroupPermissions isn't made to revoke permissions. Permissions granted via $wgGroupPermissions are cumulative, which means, that the permissions of all groups a user belongs to, reflects the permissions, the user has. If you set the edit permission of a group to false, and another group (e.g. user) has the edit permissions (set to true), the user (who belongs to both groups) will have the permission to edit. That's (maybe) a bit better explained on the Manual page (see the link above).
To achieve what you want, you need to:
Remove any other group with the edit permission from the user (that's not a good idea, if you have any other groups with special rights you get a really confusing and complex construct of permission management)
Use $wgRevokePermissions instead, see the example about how to revoke the edit permission for a group
Example to achieve what you want:
// inherit all rights from the user group
$wgGroupPermissions['test'] = $wgGroupPermissions['user'];
// revoke the edit permission for users in the group test
$wgRevokePermissions['test']['edit'] = true;
I hope that helps!
In MediaWiki, all users (including anonymous visitors) automatically belong to the group *, and all registered users (i.e. not anons) belong to the group user. By default, both of these automatic groups have the edit permission set to true, so every user can automatically edit pages.
To restrict editing to only certain users, you first need to remove those automatic edit rights by adding the following lines to your LocalSettings.php:
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['user']['edit'] = false;
Now only users in groups that have the edit permission set to true can edit pages. There are no such groups by default, so to let anyone edit anything on your wiki, you'll have to add a few more lines to LocalSettings.php. For example, here's how to let admins (i.e. users in the group sysop) edit pages:
$wgGroupPermissions['sysop']['edit'] = true;
Alternatively, as already noted by Florian, you could use $wgRevokePermissions to remove editing rights from certain users. For example, here's how to allow all registered users, except those in the group blocked, to edit:
$wgGroupPermissions['*']['edit'] = false; // anons can't edit
$wgGroupPermissions['user']['edit'] = true; // normal users can edit
$wgRevokePermissions['blocked']['edit'] = true; // "blocked" users cannot
(Of course, the built-in user blocking feature in MediaWiki accomplishes this much better.)
Another option, if you wish to restrict editing only in certain namespaces, would be to use $wgNamespaceProtection, which lets you define a custom user right needed to edit pages in certain namespaces. For example, to allow only users in the custom group editor to edit pages in the main namespace, you could use:
$wgNamespaceProtection[NS_MAIN] = array( 'edit-main' );
$wgGroupPermissions['editor']['edit-main'] = true;
i am messing around with the cakephp 2.0's access lists,
so far i created a very simple example following the documentation.
I have set up a users table and the most important functions like index, add, login ecc. and is related to a groups table (every user belongs to a group).
I've also created a "houses" table wich contain different contents (houses).
Then i've set up auth in combination with the acl-component in crud mode,
including the aco and aro tree.
So far so good, everything is working so far, i can allow or deny single actions for every user.
But, i want further access control, that for instance a user can manage only a specific house.
So i've set up an aco for every house, allowed only read-access to the houses to the user and allowed update access only for the desired house.
But it won't work! No matter what i do.. i don't get access to the edit action.
Here my trees:
Aco:
[1] Houses
[5] House.1
[6] House.2
[2] Users
Aro:
[1] superadmin
[4] User.1
[1] admin
[5] User.2
[7] User.4
[3] customer
[6] User.3
And finally the aros_acos table:
id aro_id aco_id _create _read _update _delete
4 1 1 1 1 1 1
5 1 2 1 1 1 1
6 2 1 1 1 1 1
7 3 1 0 1 0 0
8 7 1 -1 1 1 -1
9 7 5 1 1 1 1
Fact is, that, if i try to do a quick check with:
var_dump($this->Acl->check(
array('model' => 'User',
'foreign_key' => 4),
array('model' => 'House',
'foreign_key' => 1),
'update'));
It gives back true!
Strange... Am i doing something wrong? Is there any way to decently debug the acl component (with information wich acos and aros the component is checking, seeing ecc.)?
Based on your aro_aco table, it looks like this is correct behavior. User.4 belongs to the admins group which has update permission. set to true in row 8. You have a rule in row 8 specifically for User.4, but you have granted update permission specifically to that user in that row. It appears that the ACL rules are working exactly as you have them setup. To prevent User.4 from using the update permission, run this at the cake command line to update your rules for User.4:
cake acl deny User.4 House.1 update
It should then return false when you run a check:
cake acl check User.4 House.1 update
EDIT
I'm going to attempt to revise this based on comments left below. I think that you may still be setting up the rules incorrectly. I am going to use the command line examples (because it's either to both type and to do in practice) but you can just as easily write the PHP to do this. My examples below also focus on admin, but you could use for the superadmin and users groups too.
First, deny everything to admins since we want to grant permissions individually:
cake acl deny admin Houses all
Then, grant the read only permission to admin so they can all read Houses:
cake acl grant admin Houses read
Lastly, grant the update permission to the specific user that gets update privileges:
cake acl grant User.4 Houses.1 update
These permissions should allow User.4 to read and update the House record. Keep in mind that if you have already created deny or allow records for User.4 then this example may not work. You may want to truncate your aco_aro table and start over since it's small at this point.
If all acl checks work, but the behavior is still incorrect, then you may have an issue with how the ACL component is authorizing an action. You may have to tweak those settings in $beforeFilter or your $components array.