Live data from Hacker News

When was the famous "sudo warning" introduced? (2019)

retrocomputing.stackexchange.com

1–10 of 180 posts

Re: When was the famous "sudo warning" introduced? (2019)

#2
Not sure what the connection with Colorado U might be but I read this [0] a couple of days ago. Steve Bellovin had a few connections with formative Unix security and worked/studied with Fred Brooks and Ken Thompson, In the (linked) talk he says that Brooks taught him "about responsibility. Someone with the root password has not just the right but the responsibility to use it." This caught my attention because I'm writing a series "Technology: rights or responsibilities?" Maybe there's a thread of influence there?

[0] https://www.schneier.com/blog/archives/2024/11/steve-bellovi...

Re: When was the famous "sudo warning" introduced? (2019)

#5
post #3

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

And that's why we should

1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and

2) configure polkit to allow the initial human user of the machine to elevate without typing a password.

#2 is just a default, and special configurations can of course override it and return a configuration much like what we have today.

But Jesus Christ Almighty Batman, if I'm installing Ubuntu on my laptop and I, as my regular user, want to install audacity, I shouldn't have to re-enter my password!

Re: When was the famous "sudo warning" introduced? (2019)

#6
post #3

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

... and of those who have used multi-user Unix systems, very few would have had the privilege to use sudo in that context. (Unless you count managing a family computer, and even that is likely rare these days given that everyone seems to have their own machine.)

Re: When was the famous "sudo warning" introduced? (2019)

#7
post #3

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

And that's why we should 1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and 2) configure polkit to allow the initial human user of the machine to elevate without typing a password. #2 is just a default, and special configurations can of course override it and return a configuration much like what we have today. Bu…

The problem is that any command that elevates privileges introduces a potential hacking vector so while having to enter your password or provide some other authentication at points where privileges get escalated is not an unreasonable ask.

Re: When was the famous "sudo warning" introduced? (2019)

#8
post #3

It’s a funny artifact because most people today use, and have only used Linux in a “single user” context. The “local system administrator” is me!

And that's why we should 1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and 2) configure polkit to allow the initial human user of the machine to elevate without typing a password. #2 is just a default, and special configurations can of course override it and return a configuration much like what we have today. Bu…

Would biometrics that actually work solve the problem of the password for you?

Because I'm not sure it's a good idea to not require passwords. At the very least it's a way to make people pause and ask themselves if they really want to give admin rights to whatever program they're running.

Re: When was the famous "sudo warning" introduced? (2019)

#10
post #7

Earlier quoted context omitted.

And that's why we should 1) switch from using "sudo some-command --some-argument" to "some-command --some-argument" in which some-command authenticates and elevates via polkit, and 2) configure polkit to allow the initial human user of the machine to elevate without typing a password. #2 is just a default, and special configurations can of course override it and return a configuration much like what we have today. Bu…

The problem is that any command that elevates privileges introduces a potential hacking vector so while having to enter your password or provide some other authentication at points where privileges get escalated is not an unreasonable ask.

A command running in my usual shell context can just change my dotfiles to do whatever it wanted anyway. There's little value these days in the traditional root-user separation. You don't actually need "admin rights" to do practically anything malware might want to do.
Post reply on HN