If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

- Swith to 256-colors terminal messed up some archaic utilities like uerf on digital unix when I log on to those boxes (just prints stdout instead of regular output). Switching to xterm by default fixes this.

You could also change your terminal emulator config instead of changing to a different terminal emulator...

That sounds like a decision made by a developer/designer who never talks to real world users and their use cases...

From post #140

Originally Posted by eliac

Let's be clear: most normal users out there don't set up a workstation as a file server, nor do they install multiple desktop environments on their computer. A good percentage of us do that _because we are a niche of tech-savy users with different needs and skills_. But if you design for the mainstream users, then you have to choose your defaults and behaviour in a way that makes sense for them, not for your current actual niche.
How many real users do you know that had a reason to log out in a single user single - single session case but were unable to set the needed gsetting? Because I know nobody that wasn't already looking for a reason to NERDRAGE about Red Hat conspiracies and "dumbing down of interfaces" and that had real trouble with this issue.

I took the time to reproduce the issue by installating both Fluxbox and Sugar and restarting the system. On gdm login screen, the session is available containing Fluxbox and Sugar.
I do not know how you cannot access to Fluxbox while I successful got there without a fuss.

You missed what I said. It did appear, but it needed a reboot first. Anyway, I would much rather just be able to have logged out.

Sudo is another open door. Every distribution I have used allows sudo su

Ubuntu allows (full) sudo rights to the user who installed the OS (who can be considered a sysadmin by definition in most cases), but by default does not allow it for additional users (unless you explicitly make them admins too).

There usually is no point in disallowing the (main) sysadmin access to a root terminal (although obviously in most cases 'sudo -i' is a better way to get that than 'sudo su').

@finalzone:
Even if only 0.1% or less of "normal" users use this regularly (which they do), it is important that they can keep using it without any trouble. It is a supported feature (as the developers publicly explains how to re-enable it), and there is no way it will confuse users who don't need it (AFAICT), so it makes no sense at all to hide it.

I remember sudo being 'invented' for people who have difficulty remembering that they are going to do something as root.

That is not why sudo was invented; it was "invented" to allow certain users to run certain applications (with certain options) as root (or as a certain user) without (necessarily) needing the root password (or the password of that certain user).

That is not why sudo was invented; it was "invented" to allow certain users to run certain applications (with certain options) as root (or as a certain user) without (necessarily) needing the root password (or the password of that certain user).

Additionally, it also logs every invocation.

Not quite. It was written because gnu su will never limit users from root access because someone decided RMS didn't need root access at MIT (he probably didn't) and it scarred him for life.

Sometimes a few of the users try to hold total power over all the rest. For example, in 1984, a few users at the MIT AI lab decided to seize power by changing the operator password on the Twenex system and keeping it secret from everyone else. (I was able to thwart this coup and give power back to the users by patching the kernel, but I wouldn't know how to do that in Unix.)

However, occasionally the rulers do tell someone. Under the usual su mechanism, once someone learns the root password who sympathizes with the ordinary users, he or she can tell the rest. The “wheel group” feature would make this impossible, and thus cement the power of the rulers.

Leslie, please don't recommend people log in graphically as root. It is highly insecure and not to be advised in any case for any reason. Fedora is not designed to encourage this.

===
Please enumerate how logging in as root in GUI mode is more dangerous than using command line when.
a) Yum is not executed, nor any internet access
b) Gui mode is used to allow me to manage files and directories without the problems arising from a keying in error.
c) Want a list of key-in errors, just look at typos, look at rm *~ vs rm * ~
d) moving files from ../.././abc.c /opt/country/province/state/client/src and doing a mark and paste

So, please tell me what I am overlooking to make logging in as root more dangerous.
For years I have modifed pam.d files to allow root to logon in aui environment. So far, no past history of attacks as external web access is not used, and I am confident that no gui file or bash, bashrc etc has been modified.

I use common sense. Does that not exist any more.

I await your one example that will change my work habits.

I am not stubborn to reject changing my ways of doing things. I just would like one justification.