pfSense

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?

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.

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.

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.