Red Hat Bugzilla – Bug 503873
clarify message if GUI root access denied
Last modified: 2015-01-14 18:23:06 EST
Description of problem:
We need GUI root access for security.
Version-Release number of selected component (if applicable):
Happened twice. I assume not intermittent.
Steps to Reproduce:
1. Turn wireless off at the hardware level and physically yank all NICs or their cables, for security against permanent damage while a firewall is lacking. Do not depend on software or firmware to keep networking off.
2. Cleanly install Fedora 10.
3. Try to enter the root account.
4. See a message that the user cannot be authenticated.
5. Enter the only user account available.
6. Observe that su works in a terminal, thus verifying that the root password works for some purposes.
7. Look in help and in F10 book and see nothing on point.
8. Reinstall cleanly and see the same thing happen, even with passing a media check.
root is denied access. Denial behavior is that of system being broken.
root should be granted access. That should be an installation-stage option. If denial is deliberate, the message should not mislead.
What happens during installation and login is a heavy set of clues that the software is broken. I wiped F10 off and cleanly reinstalled Fedora Core 4. By now I had spent hours just on the two additional installs. Only when I asked a forum for help did I learn that root denial was deliberate. As an experiment, from a FC4 user account I used su and "su -" (without quote marks) and tried to edit /etc files but lacked permissions.
Either everything can be done using "su -" or not everything can be; the latter is crippling, but the former is also problematic. Terminal use denies a GUI and that's a security problem because a good GUI (and most are good in this sense) offers command cues, cautions, and feedback that reduce errors. And I don't know how to determine the CLI equivalents of GUI menu app names, nor of applications' menu commands and dialog options. I think I have over 50-100 files with the string "mysql" in the filenames and yet I still haven't figured out how to start MySQL, which isn't in a menu. So having to work in a CLI means I can still do dangerous things like erase my whole hard drive (and I haven't had that accident yet) but I can't safely run utility programs I already know how to use. So su is less useful than normal root access. FC4 gives me root access.
Also relevant is Bug 447266.
I hope to confirm the F10 file edit that I've read allows root access, and verify that it doesn't have any bad side effects.
I think I can get around a complete lack of root and su access by booting from a floppy with Hal91 Linux, either locally editing or copying, remotely editing, and replacing files, and rebooting into hard-drive F10. I'm not sure that isn't riskier than simply allowing root access.
But I see why someone installing for users might want to disable root and maybe restrict su.
Recommendation: Add a step to the installation process so an installing person may opt for root access.
Having something like this in anaconda isn't really possible as it ties anaconda more closely to the specific quirks of a single distribution release and that's the opposite of the direction we're trying to move in. The decision to not allow root logins through the desktop wasn't an anaconda one. It was made as a desktop-wide and distribution-wide policy. anaconda is not in the business of offering workarounds to defined Fedora policy.
You can configure gdm to allow root logins, though since I do not work on it, I do not know how. The fact that su - does not allow you to do things definitely sounds like a bug, though. It could be a problem with selinux or with su itself.
In that case, at least please reword the message that results from refusing root access. To say that the user cannot be authenticated is to say either that the user has forgotten their root password or that the software just installed is broken. In either case, reinstalling or getting another OS is necessary. To make that unnecessary, use phrasing that's more relevant.
A technical problem -- I'm guessing how root access is being denied -- is that Fedora may be denying the GUI login process access to /etc/shadow if the user is root and thus is not trying to check the password itself. That, too, can be solved.
If the user being attempted for login is root, post a message such as, "root may not log in here but should use the terminal or console. The root password has not been authenticated."
If that is not generic enough because it should apply to any user similarly situated, phrase thus: "This user may not log in here but should use the terminal or console. The user's password has not been authenticated."
This does not create a security risk in telling an attacker too much. Assuming an attacker does not know about the Fedora policy, an attacker aware of Linux almost certainly knows the key account is named "root" and so won't assume the account was misnamed and therefore will "know" that only the password is wrong. If the concern is that they shouldn't know about the console/terminal being an alternative if the GUI fails, allow the superuser to configure a setting to choose the vaguer message, i.e., the one that displays nowadays about not authenticating the user. That's good for a superuser who already knows about this policy but may not want another user to know.
I don't understand why the proposal would be too narrowly applicable to one release, unless there's a plan to restore GUI rooot access in a future release. But if the more basic decision remains denial of GUI root access, there may be no justification in changing anaconda.
The su problem I experienced wasn't in F10, since, not knowing that I wasn't supposed to succeed via the GUI, I had already wiped F10 off the disk and couldn't test F10 terminal access anymore. The su experimentation was in FC4, where I didn't try changing permissions to edit /etc files, and FC4 terminal experience might not be entirely germane to F10.
Although I disagree with the denial as policy without a workaround, so that if a workaround is too problematic I'll probably switch to another distro, the policy may make sense for the kinds of institutions for which RHEL is marketed.
That leaves the phrasing as the main issue.
I edited the summary (title) of this bug.
This message is a reminder that Fedora 10 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 10. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora
'version' of '10'.
Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version prior to Fedora 10's end of life.
Bug Reporter: Thank you for reporting this issue and we are sorry that
we may not be able to fix it before Fedora 10 is end of life. If you
would still like to see this bug fixed and are able to reproduce it
against a later version of Fedora please change the 'version' of this
bug to the applicable version. If you are unable to change the version,
please add a comment here and someone will do it for you.
Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.
The process we are following is described here:
Fedora 10 changed to end-of-life (EOL) status on 2009-12-17. Fedora 10 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.
If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version.
Thank you for reporting this bug and we are sorry it could not be fixed.