Valent Turkovic escribió:
On Wed, Mar 26, 2008 at 10:12 PM, Gian Paolo Mureddu
<gmureddu@xxxxxxxxxxxxxx> 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"?
--
Fedora-desktop-list mailing list
Fedora-desktop-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-desktop-list
