Red Hat Bugzilla – Bug 128308
system-control-network fails to prompt for superuser password when required
Last modified: 2008-05-06 20:00:03 EDT
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"
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):
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.
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:
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: