Project

General

Profile

Bug #9259

User with "Deny Config Write" privilege is not fully prevented from creating accounts

Added by Stefan Beckers over 1 year ago. Updated 2 months ago.

Status:
Resolved
Priority:
Normal
Assignee:
Category:
User Manager / Privileges
Target version:
Start date:
01/07/2019
Due date:
% Done:

100%

Estimated time:
Affected Version:
2.3.4_1
Affected Architecture:
All

Description

I do log into the web GUI as a user "myuser" with admin group membership (other than the builtin admin/root). I used to be able to add a user to the system.

Now the creation of a new user fails and

  • the console gives me hostname php-fpm[12038]: Save config permission denied by the 'User - Config: Deny Config Write' permission for user 'myuser@192.168.1.1 (Local Database)'.
  • The user is invisible in the GUI
  • The user was created in /etc/passwd and the rest of the system

I have not altered the "admin" group and "myuser" is member in the admin group. We do have other groups with restrictions, which do not apply to the user "myuser", used above.

Interestingly the next try on the GUI fails, stating in the GUI "That username is reserved by the system." Reason: the new user was created on system level but stays invisible in the web GUI.

How to resolve this:
  • Clean up the system from your last try
    • rmuser
  • log in as buildtin "admin" user on web GUI
  • create user as usual
diff_usermanager.txt (1.08 KB) diff_usermanager.txt Martin VENÇON, 05/07/2020 04:29 AM

Associated revisions

Revision acd7e560 (diff)
Added by Jim Pingle 11 months ago

User & Group Manager: Improve Deny Config Write Handling. Fixes #9259

  • Denies all changes if a user has the Deny Config Write privilege.
    Previously it only denied the config write but some OS operations were
    performed.
  • Sets an input error so the user is notified that their attempt failed.
  • Hides the add and delete buttons so read only users don't see the
    option to perform those actions (but are still denied if they submit the
    form through other means)

Revision 585bbbd3 (diff)
Added by Jim Pingle 11 months ago

User & Group Manager: Improve Deny Config Write Handling. Fixes #9259

  • Denies all changes if a user has the Deny Config Write privilege.
    Previously it only denied the config write but some OS operations were
    performed.
  • Sets an input error so the user is notified that their attempt failed.
  • Hides the add and delete buttons so read only users don't see the
    option to perform those actions (but are still denied if they submit the
    form through other means)

(cherry picked from commit acd7e5601ac6bc8b079bd6ea7f8b637a5ec89b5f)

Revision e6c79cd3 (diff)
Added by Jim Pingle 2 months ago

Update user index after making changes. Fixes #9259

Revision 46764785 (diff)
Added by Jim Pingle 2 months ago

Update user index after making changes. Fixes #9259

(cherry picked from commit e6c79cd3aafdbd25971a62103b51584335523e33)

History

#1 Updated by Jim Pingle over 1 year ago

  • Subject changed from Creating a new user on Backend local Database fails halfways, when done with account other that buildtin "admin" to User with "Deny Config Write" privilege is not fully prevented from creating accounts
  • Assignee changed from Renato Botelho to Jim Pingle
  • Target version set to 48
  • Affected Architecture All added
  • Affected Architecture deleted ()

You must have incorrectly added the "User - Config: Deny Config Write" privilege to your admin group, which is common when unnecessarily using "select all" on the privilege list without considering the consequences.

There is still a bug here, but it did deny the config.xml change as expected. Since that was not technically a config.xml change, the privilege did what it was told to do and blocked only the config.xml change. It should probably also block the shell account portion from being added.

#2 Updated by Stefan Beckers over 1 year ago

That is not the case. I just have tried another system, where this issue does not show. My latest install does behave well.

At least on all three systems, I have compared yet, the "custom" admin users do have
  • admins WebCfg - All pages Allow access to all pages (admin privilege)
the "admin" user does have:
  • admins WebCfg - All pages Allow access to all pages (admin privilege)
  • User - System: Shell account access Indicates whether the user is able to login for example via SSH. (admin privilege)

and the admin group only has

  • "WebCfg - All pages Allow access to all pages (admin privilege)"

assigned.

It is not like that only older systems which have undergone multiple Updates and Upgrades and lots of configuration changes. It seems to be showing only on some systems. Others do behave well.

Any additional information I can compile for you here?

#3 Updated by Jim Pingle over 1 year ago

The only way you can see that "Deny Config Write" message is if your user, or a group they are in, has the "Deny Config Write" privilege. That is 100% a configuration error and not the bug you are seeing here.

The other systems work because you don't have "Deny Config Write" in those privilege lists.

If you need more explanation, post on the forum.

#4 Updated by Jim Pingle over 1 year ago

  • Target version changed from 48 to 2.5.0

#5 Updated by Jim Pingle 11 months ago

  • Status changed from New to Feedback
  • % Done changed from 0 to 100

#6 Updated by Jim Pingle 8 months ago

  • Target version changed from 2.5.0 to 2.4.5

#7 Updated by Jim Pingle 7 months ago

  • Status changed from Feedback to Resolved

Works as expected on 2.4.5.a.20191218.2354

GUI user is not presented with options to add an account. If they do manage to submit the form, an error is generated and no account is created in the GUI or the OS.

#8 Updated by Martin VENÇON 2 months ago

Hello,

I experienced the same issue described here, and the last changes that you have made did not fix the problem.

When a user (not the admin account) within a group that have the privileges to add a user, try to add another user, the error described in the issue appeared.

With a bit of digging, I realized that the variable $userindex from auth.inc is not updated when adding a new user. This causes the function getUserEntry to return the wrong user (that may not have the right privileges) and entail the error in the write_config function.

Example:
Reader has the privilege read-config-only so he cannot wwite in the config file.
Secuadmin does not have this privilege and can create users.

$userindex => ["admin" -> 0, "reader" -> 1, "secuadmin" -> 2]
$config['system']['user'] => contains those 3 users in the same order

Let's say we add a user called Dave.

$userindex stays the same.
$config['system']['user'] now contains 4 users and Dave has been inserted in second position (admin, Dave, reader, secuadmin).

$userindex has not been updated, getUserEntry(secuadmin) returns $config['system']['user'][2], which is the user "reader" and causes the problem.

Please find attached to this message a fix suggestion.

Martin

#9 Updated by Jim Pingle 2 months ago

I can't reproduce that problem. I've tried creating an account, deleting an account, various other actions, but nothing succeeds so long as the user has the user-config-readonly privilege. The error "Insufficient privileges to make the requested change (read only)" is displayed every time. Is it possible you're leaving out an intermediate step or two?

I tried two different ways:

1. Logged in as a read-only user, users before and after in the list both had full admin privileges. Manually went to create account page while logged in with that account. From another browser, I added a user. Then from the read-only user I tried to create an account. It failed, as expected. No changes were made in the GUI and the user was not present in /etc/passwd. Then I did the same with deleting an account. That also failed as expected.
2. Logged in as a an admin group member without user-config-readonly, opened the create account page, filled it in, switched to the other browser, created a new account there first, then swapped back and tried to create the other account. That also worked, as expected.

In each path I only saw the expected actions happen. A user with write access can create and delete. A user with user-config-readonly cannot create or delete. I never saw a disagreement between the GUI user and /etc/passwd

How did the user with user-config-readonly even get to a point where it could make the changes you are describing? Or am I misunderstanding what you're saying?

Maybe if you list out each step you took exactly in order it would help.

#10 Updated by Martin VENÇON 2 months ago

Hello Jim,

The issue with this problem is that even in my case, I could not reproduce the issue 100% of the time. The described behavior only appeared once in a while. Now from my experience with this, it seems like the array $config['system']['user'] is sorted alphabetically so you might want to have the usernames sorted in a specific way for the issue to appear.
But I kept doing the following steps to reproduce it:

1. Log in as the standard admin user
2. Create 2 groups, one with user-config-readonly, and one with enough privileges to create a user
3. Create 2 additional users (on top of the admin user) with the names "reader" and "secuadmin" for the read-only group and the pseudo-admin group respectively.
Please note that the users are ordered as follow: [0 -> admin, 1 -> reader, 2 -> secuadmin], in the $userindex and $config['system']['user'] arrays.
4. Log out of the admin account and log in as the other admin-privileged account (secuadmin in my case)
5. Create a user with a username between 'a' and 'r' (let's say 'dave' with a lower-case 'd') so that is it inserted between the first and second entry (admin and reader in my case). The problem should appear, an entry is created in /etc/passwd and you get the message Save config permission denied

As I described in my previous post, this appears because the global variable $userindex from auth.inc is not updated, and because of the way the users are ordered in $config['system']['user'], the function getUserEntry returns another user from the current user on the web GUI.

I hope you can successfully reproduce the error. I will stay available if you have any other question/need of information.

Martin

Edit: I did not mentioned the browser I used, which is Firefox. I do not think it has an impact but just in case.

#11 Updated by Jim Pingle 2 months ago

  • Status changed from Resolved to Confirmed
  • Target version changed from 2.4.5 to 2.4.5-p1

OK, with those exact steps I can reproduce it, but only if I start without any other users. There must be some other component to it, but reindexing the users does appear to correct the behavior.

#12 Updated by Jim Pingle 2 months ago

  • Status changed from Confirmed to Feedback

#13 Updated by Jim Pingle 2 months ago

  • Status changed from Feedback to Resolved

Unable to reproduce the problem after the latest commit.

Also available in: Atom PDF