Valent Turkovic escribió:
On Wed, Mar 26, 2008 at 10:12 PM, Gian Paolo Mureddu gmureddu@prodigy.net.mx wrote:
Jesse Keating escribió:
On Tue, 2008-03-25 at 12:02 -0600, Gian Paolo Mureddu wrote:
but being as /sbin paths are meant for administrative tasks, I actually do see having them as part of a regular user's PATH a potential security risk.
That's completely bogus. A "hidden path" offers 0 security. If you don't want your users running them, set the permissions on the binary, or better yet, have the binary check the EUID of the caller. If non-root, display that the command is for root users, but also allow the user to get --help and other usage or informational output from the command. Just don't allow non-root users to apply anything. There really is no reason I can think of to hide this crap in a different directory. It just adds needless complication and confusion.
Sarcastic disclaimer.
Why not install all binaries into /bin, /usr/bin, /usr/local/bin and be done with it, then? Why EVEN have another path, anyway? Better yet, why don't we follow Ubuntu and make sudo the default, make regular users have admin rights! Why do we even need root? What's that? Geeze, I mean why even keep an ancient file system layout?
sudo adds also security so that is also a bonus.
Valent.
Not much... users more often than not use very, very weak passwords easily crackable. With sudo enabled by default that imposes a serious security risk. Also there are things that can't be done with sudo like quick scripting of the CLI (say a one liner for-in loop with file operations, or at least I haven't found an efficient enough way to use them in sudo, hence I much rather prefer a dedicated root account). Certainly the paradigm of root is that of the system administrators, but it certainly is better to have the users and administrative tasks separated. Policy Kit looks like a more robust solution than sudo and still allows for a full blown root account. I guess the bottom line is with each paradigm there are compromises that have to be made... The point is "which compromises does Fedora want to do make"?