Bug #2245
closed
User permissions for shell access are not clear/complete
Added by Stilez y over 13 years ago.
Updated almost 11 years ago.
Description
I wanted to rename the main "admin" account to avoid easy login guesses. The default account cannot be renamed within pfsense so I created a new account in user manager, gave it the same group membership as the existing one (member of "admins") and disabled the existing "admin".
Bug - the new account was blocked from accessing the vga console while the inbuilt one was able to. When the new account logs in on the vga console it's dumped into a crippled/permission-limited shell and can't be used for administration or emergency recovery functions (for example, basic commands such as pfctl -d get "permission denied" errors).
It's important to have a way to avoid the default login username but this bug makes it impossible as only the default account can get into the normal VGA console.
Screenshot available, reproducible even after full clean reinstall.
One side-point - the definitions used in security groups are slightly misleading (see bug 2247). I checked, this doesn't affect the current bug.
- Status changed from New to Rejected
That is by design. It can't work any differently without some extra package like sudo (which has been considered, not sure what the status is on that)
If a new account, apparently given identical permissions in the interface, doesn't actually have identical permissions and can't access key functions, it needs to say so. At a minimum pfsense:
- the built-in admin account should be given a distinct group to which other users cannot be added, so new admin accounts can't be added to the same group. It's incorrect for User Manager to suggest other user accounts will be allowed the same rights as the built-in account if they won't.
- user-created groups should show access rights such as the shell interface as "dimmed out", so it's clear user-created admin accounts can't be granted access to them.
It's basic, if two accounts aren't going to get the same permissions then they should visibly be seen to not have the same permissions.
The bug in this item isn't that the access rights can't be granted or need sudo, or that by design user created admins can't get vga console login. The bug is that the user configuring user rights is misinformed about the rights actually granted. Manually created admin accounts will be given rights that do not match what the interface says (and is reasonably believed) was given. Can that be fixed at least?
- Status changed from Rejected to New
Rather than reopen that old ticket (I thought it was still open) I'll leave this open since it's more specific, and the original issue of the old ticket was fixed.
- A group would not be correct for that, and would break quite a bit with how groups operate. Simply listing an additional permission would be sufficient. The permission display for admin was broken in 2.0 and 2.0.1, and has since been fixed in master and RELENG_2_0.
- That isn't valid either because the user can get shell access to do various things, just not the root/admin functions. People use that now and are happy with it, to break that would not be good. The user is given shell access, that is not misrepresented, and shouldn't be changed. The description could be expanded to indicate it does not grant the same permissions as admin/root.
An additional permission for "shell+sudo" access would bridge the gap, not break existing users, and if presented next to the other options, would make it even more clear to the user that the other shell permission lacks such access.
- Subject changed from New users defined as members of "admins" cannot access all functions to User permissions for shell access are not clear/complete
Worth noting, the "crippled admin" accounts (ie members of "admins" that aren't the built-in account) also have limited access to Webcfg functions. For example a user-created admin cannot edit router rules saved under /etc/inc using "File Manager" package, it silently fails. Possibly other packages have functions that don't work for "admin" accounts other than the inbuilt admin account.
So it looks like functions such as using the web access to edit router config files can't be given by the router's controller to anyone else except by providing them with access to the inbuilt root account. Problem for when router config is to be shared or delegated but root access isn't to be given?
Stilez y wrote:
Worth noting, the "crippled admin" accounts (ie members of "admins" that aren't the built-in account) also have limited access to Webcfg functions. For example a user-created admin cannot edit router rules saved under /etc/inc using "File Manager" package, it silently fails. Possibly other packages have functions that don't work for "admin" accounts other than the inbuilt admin account.
So it looks like functions such as using the web access to edit router config files can't be given by the router's controller to anyone else except by providing them with access to the inbuilt root account. Problem for when router config is to be shared or delegated but root access isn't to be given?
I have never seen that, the web server itself runs as root and doesn't change permissions in the backend based on the user. One of many reasons you don't want to hand out access to exec.php and friends lightly. That may be an issue with that one package, editing files using Diagnostics > Edit File works fine. Again, these kinds of things are best discussed in the forum and do not belong in the ticket system until they are confirmed to be relevant.
- Status changed from New to Resolved
resolution Jim noted has since been implemented, which resolves the only real issue I see here.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by