Rick Stevens wrote: > On 04/15/2010 09:01 AM, R. G. Newbury wrote: >> On 04/15/2010 10:12 AM, users-request@xxxxxxxxxxxxxxxxxxxxxxx wrote: >>> From: "Dr. Michael J. Chudobiak"<mjc@xxxxxxxxxxxxxxx> >>> Subject: Re: Root with GUI >> >>> On 04/15/2010 08:24 AM, Richard Shaw wrote: >>>>> On Thu, Apr 15, 2010 at 7:21 AM,<hewjr1000@xxxxxxxxx> wrote: >>>>>>> How do I make myself root in the GUI >> >>>>> Running a root GUI login is very much frowned upon. >> >> You forgot the stage directions: "Folds arms across chest, wags finger >> at suitably cowed and humiliated user.." > > Oh, come now! > >> It's 'frowned upon' by religious zealots who wish to impose their 'the >> sky could fall' fears upon everyone. A***oles piss me off. > > Those who accuse people who caution against this very ill-advised > practice "religious zealots" or "A***oles" certainly demonstrate their > massive experience and maturity, don't they? > Being immature, opinionated, or even certifiably insane doesn't make him wrong. Those things are not mutually exclusive to being right. > In my 35 years of being in this business, I've had to support a large > number of Linux, BSD and SYSV systems in the hands of former Windows > users (and others with similar brain damage). I can say from > experience that a root-based GUI is a very dangerous thing and those > who claim otherwise either haven't supported large numbers of neophyte > users or have been extraordinarily fortunate to have escaped unscathed. > Root access by incompetents is a bad thing, the interface is moot. But at any level of competence forcing people to do things in a complex and unfamiliar way make errors more likely. I have scripts to do things I only do a few times a year, as well as set of notes that would have been a wiki had there been such a thing when I started. Bozo should not have root, anyone so trusted should be allowed to use the best tools available. > It so very much easier to damage a system from the GUI than from a > command line. A single icon click or "Proceed" click can run literally > tens or hundreds of CLI commands. As root, there's no restriction on > what's run. Brilliant! The ramifications can be (and have been) > devastating in my experience. This is specifically why root-based GUIs > have been disabled by default. > Your whole argument only makes sense if you accept the first sentence as true. And frankly I don't, at least using standard Fedora menus. What tools do you install that would wreak such havoc? I'm looking at the menus (FC13 at the moment) and I find the set of things needing root and the set of things a user trusted with root would want to do have little overlap and minimum danger. Unless you trust root to people who are clearly incompetent, what would they do from GUI that they could screw up worse trying to do it from CLI? Some users have never *seen* a CLI, and find it a "neat new feature." I didn't make that quote up. ;-) > All that being said, if one is a godlike user and/or is willing to > deal with the carnage that can (note I said _can_) ensue with root- > based GUIs, then by all means edit the pam files and have at it. No > one is stopping you. > Good. Because if you have root password then all you have accomplished with nanny login is to force the user to type the root password for every GUI, or force the user to try to use su and a possibly unfamiliar CLI to do things. I have a high resistance to giving "just users" root in any way, much less blocking access to tools which might do the wrong thing but would at least do it correctly. I have pissed off several managers by requesting a signed authorization to give root to people who are not administrators. And covered my ass once with just such a paper, I am not a trusting person. -- Bill Davidsen <davidsen@xxxxxxx> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot -- users mailing list users@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe or change subscription options: https://admin.fedoraproject.org/mailman/listinfo/users Guidelines: http://fedoraproject.org/wiki/Mailing_list_guidelines
