Description of problem: User with blank password can change network configurations in Gnome GUI without asking for root's password This will happen even USERCTL=no in ifcfg file. Version-Release number of selected component (if applicable): Fedora 8 How reproducible: To set the user with blank password, delete the password strings in shadow file. then, startx, select administration, Network, All network devices can be modified. Steps to Reproduce: 1. delete the password string in shadow to set blank password for user. 2. startx 3. select Administration, all functions can be locked but Network ! Actual results: User can get the full control of network devices even USERCTL=no in ifcfg files. Expected results: User should not control the network devices due to USERCTL=no Additional info:
USERCTL=yes does only permit activation/deactivation... not modification modification relies on consolehelper from usermode
$ ls -l /usr/bin/system-config-network lrwxrwxrwx 1 root root 13 2008-04-27 14:09 /usr/bin/system-config-network -> consolehelper
USERCTL=no also allows "blank password" user to activate / deactivate the network device in GUI mode.
Thanks for your report. This seems to be working fine for me. Can you describe the steps more precisely, please? * Which application are you exactly starting? What is the name in the menu? What is the window title? * What exact action is allowed by "full control"? What specific buttons/menu items can you use and what is the effect? * Is there a root password set? Does (su -) require a password? * Please attach the output of the following commands, when run from a terminal window in the same X session: - id -a - ls -l /usr/sbin/usernetctl - cat /etc/sysconfig/network-scripts/ifcfg-DEVICE, where DEVICE is the device you can manipulate but shouldn't be able to - cat /etc/pam.d/system-config-network - cat /etc/security/console.apps/system-config-network - cat /etc/security/console.apps/config-util
The information we've requested above is required in order to review this problem report further and diagnose or fix the issue if it is still present. Since it has been thirty days or more since we first requested additional information, we're assuming the problem is either no longer present in the current Fedora release, or that there is no longer any interest in tracking the problem. Setting status to "CLOSED: INSUFFICIENT_DATA". If you still experience this problem after updating to our latest Fedora release and can provide the information previously requested, please feel free to reopen the bug report. Thank you in advance.