From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040116 Description of problem: The system-control-network tool does not attempt to run as the root user when needed. The "Activate" and "Deactivate" buttons don't work either, for the same reason. If the user clicks "Configure", THEN the root password is asked for, and the user can use the "Activate" and "Decativate" buttons there. Most seriously, the program will fail to show ANY interfaces when started by an unpriveleged user, unless someone has started the tool as the root user prior to that. This appears to be because the profiles can not be created, as they are stored in a location only root can write to. This either needs to be changed, have the program request the superuser password on first boot, or have the profile created upon install. Version-Release number of selected component (if applicable): 1.3.16 How reproducible: Always Steps to Reproduce: 1. Install Fedora Core 2. 2. Log in as unpriveleged user (nobody should ever run X as root, right?) and launch "Network Device Control" from the Gnome menu. Actual Results: The program should start, and show available interfaces. Expected Results: The program starts, but no interfaces are shown. Additional info:
This is intended, because it should show only interfaces, which the user can control.
There appears to be a misunderstanding of this bug report. I will try to explain again. Your statement is incorrect. The program CAN be used by nonprivileged users to control interfaces they normally can not control. This is because the program DOES prompt the user for the supervisor password so that the user CAN control the interfaces- however, this is is only done if the user selects the "Configure" option from the menu, not the "Activate" or "Deactivate" buttons. This is the first problem, as this prompt should be done for all three options if the user does not have sufficient access. The second problem is that the program stores the profile information in a location that only root can write to. So, in order for nonprivileged users to use the tool, the program first needs to be started by the superuser to generate the profile information. The superuser does not actually have to USE the tool, just launch it and exit it. THEN, and ONLY THEN, can unpriveleged users use the tool in the way described in the first paragraph. If you take a moment to reproduce this, you will understand. This program worked PROPERLY in Red Hat 9, as it always prompted the user for the supervisor password when it was started, which was the design of the program. This functionality was removed in Fedora Core 1 or 2, which causes the tool to operate in the odd manner described. I am guessing that someone removed this, thinking that it would be good to allow users to work with interfaces that they did not need the supervisor password to use, but without knowing that this change would have other implications. This IS a bug- not only one bug, but two bugs, related to the same issue. I hope that this helps clarify these problems for you.
hmm, you are not asked for the root pw, because this is a user tool. admins should use redhat-config-network. but you are right.. probably we should also provide a redhat-control-network with root mode
system-control-network is actually a replacement for redhat-control-network (well, it is basically the same program, with some changes and a different package name). system-control-network itself probably needs to be changed to have it handle both the situation where a user needs to change an interface they have access to (and they don't have the superuser password) and also the situation where they have the superuser password, and need to work with an interface they don't normally have access to. Showing all of the interfaces and prompting the user for the superuser password when needed would be the most intuitive. And, it needs to store profile information in the user's home directory, or someplace that a regular user can write to. Writing under /etc probably made sense back when the tool always required the root password, but obviously not anymore.
Fedora Core 2 is now maintained by the Fedora Legacy project for security updates only. If this problem is a security issue, please reopen and reassign to the Fedora Legacy product. If it is not a security issue and hasn't been resolved in the current FC3 updates or in the FC4 test release, reopen and change the version to match.
Based on the date this bug was created, it appears to have been reported against rawhide during the development of a Fedora release that is no longer maintained. In order to refocus our efforts as a project we are flagging all of the open bugs for releases which are no longer maintained. If this bug remains in NEEDINFO thirty (30) days from now, we will automatically close it. If you can reproduce this bug in a maintained Fedora version (7, 8, or rawhide), please change this bug to the respective version and change the status to ASSIGNED. (If you're unable to change the bug's version or status, add a comment to the bug and someone will change it for you.) Thanks for your help, and we apologize again that we haven't handled these issues to this point. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp We will be following the process here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this doesn't happen again.
This bug has been in NEEDINFO for more than 30 days since feedback was first requested. As a result we are closing it. If you can reproduce this bug in the future against a maintained Fedora version please feel free to reopen it against that version. The process we're following is outlined here: http://fedoraproject.org/wiki/BugZappers/F9CleanUp