R. G. Newbury wrote: >> No - GUIs run as root are not as secure. A bug that would be caught >> when running as a user may not be caught when running as root. > > A "bug" or a permissions error. Please explain how a BUG could or would > be treated differently depending on the user? > Trying to read or write a file or device you do not have permission to access. A program that tries to use all system resources - users have strictor limits then root does. >> The more code you have running as root, the greater the chance of >> running into problems. > > This is illogical and not relevant to the point which you are attempting > to make. The vast majority of user, including myself, do not write the > code we run. And the exploit rate in code has nothing to do with the > amount of code you have running. Lots of code is basically impervious to > external exploit while being run, because it does not talk to or > interact with the external world. > He is not primarily talking about exploits, though that is part of it. The damage that can be done by a bug in a program are much greater if the program is running as root. This is one reason that SUID programs drop privileges as soon as they no longer need them. > If you are referring to the underlying OS, it ALWAYS runs as whatever, > often as root. A 'root' user doesn't to my understanding run 'more' code > than a user does...and in any event, all of that code is still there to > be exploited whichever user is running on top of it (if that code is > capable of being exploited at all). > You are not understanding what is being said - it is not they root is running more programs, but more programs are running with root privileges when you log in as root. Process that would normally be run as a normal user are being run as root. > Then again, it is a lot easier to shoot >> yourself in the foot running as root using the GUI. How may times >> have we seen someone on the list that changed permissions, or >> deleted the wrong file, and needs help to get the system running again. > > THIS HAS NOTHING TO DO WITH SECURITY. You are just trying to play > 'nanny'. The saying is: "To err is human". We are ALL human. Get over it > and stop trying to tie people's hands just because you will not be there > to hold them. AND this has nothing to do with logging in as root. Any > user, who through ignorance or stupidity (or both) changes permissions > or deletes the wrong file, is NOT interacting with "security" when he > does those things. He is using the OS, which does *exactly* what he > tells it to do, whether or not that is what he thought he wanted it to > do. And the only PROPER response to that, after the fact, is to explain > what he did (fix the ignorance bit: "ignorant" from "does not know") and > hope that he remembers it (you cannot fix the stupid bit). Oh, and say, > Don't do that again. > > Sorta like your mother probably did many times when you were a child. > But it is time to stop playing parent to everyone. > > Geoff > Nope - we are not trying to play 'nanny'. If you do not see what this has to do with security, then I feel sorry for you, and hope that it is just your home system that you are putting at risk. The defaults are to protect people that are learning. You could think of it this way - you child-prof your home when you have small children because it is hard to learn when learning kills you. How much does a new user learn when the only fix is to re-install the system? How much does it cost if your bring down the network at work because you made a mistake when running as root? Just killing your desktop at work is going to cost in lost productivity. (Unless you are not productive at work anyway - then having your system trashed may stop you from lowering others productivity.) Mikkel -- Do not meddle in the affairs of dragons, for thou art crunchy and taste good with Ketchup!
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
