Bug 128308 - system-control-network fails to prompt for superuser password when required
system-control-network fails to prompt for superuser password when required
Product: Fedora
Classification: Fedora
Component: system-config-network (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Harald Hoyer
Depends On:
  Show dependency treegraph
Reported: 2004-07-21 12:21 EDT by Darren Gamble
Modified: 2008-05-06 20:00 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-05-06 20:00:03 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Darren Gamble 2004-07-21 12:21:07 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"
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):

How reproducible:

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:
Comment 1 Harald Hoyer 2004-07-22 05:20:15 EDT
This is intended, because it should show only interfaces, which the
user can control.
Comment 2 Darren Gamble 2004-07-22 11:10:25 EDT
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.
Comment 3 Harald Hoyer 2004-07-22 11:55:35 EDT
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
Comment 4 Darren Gamble 2004-07-22 12:12:21 EDT
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.
Comment 5 Matthew Miller 2005-04-26 11:07:00 EDT
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.
Comment 6 Bug Zapper 2008-04-03 11:37:19 EDT
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.
Comment 7 Bug Zapper 2008-05-06 20:00:01 EDT
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:

Note You need to log in before you can comment on or make changes to this bug.