10 ms·

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

158 points by Boogie_Man 2y ago

nonrandomstring 2y ago
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-bellovins-retirement-talk.html https://www.schneier.com/blog/archives/2024/11/steve-bellovi...
- xyse53 2y ago
  https://en.m.wikipedia.org/wiki/Evi_Nemeth https://en.m.wikipedia.org/wiki/Evi_Nemeth was part of the early development of sudo. I did a double take years ago running "The Woz Lab" at CU Boulder, reading the sudoers man page and seeing the 128.138 address space in the examples that I was managing subnets of.
pram 2y ago
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!
- amelius 2y ago
  Yeah, the threat model has shifted in recent years from other users to applications downloaded over the internet. It is a pity that OS security has not caught up.
- Boogie_Man 2y ago
  I often give myself stern talking tos when I made ignorant sysadmin decisions
  - 0xbadcafebee 2y ago
    I put myself on a PIP for losing my backups. If I'm not careful I might fire my ass
- quotemstr 2y ago
  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!
  - monsieurbanana 2y ago
    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.
  - dhosek 2y ago
    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.
    - quotemstr 2y ago
      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.
    - alwayslikethis 2y ago
      I don't think privilege escalation is a big concern on most personal systems. If you run any malicious code, even unprivileged, you're basically already screwed anyways since the code can access all of your home, upload it, delete/encrypt it, etc. https://xkcd.com/1200/ https://xkcd.com/1200/
- II2II 2y ago
  ... 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.)
  - codetrotter 2y ago
    I was member of a student union at my university, for people interested in computers. We had desktop computers and servers that belonged to the student union, and member students would eventually be granted sudo privileges if they had a reason to need it. When they gave me and my friends sudo privileges they told us basically the sudo lecture. Use it for good, don’t snoop in other students files, and be careful to not break stuff. They even had a real-life story of their own, about one past member that was kicked out of the union because he had used his sudo privileges to read solutions to an assignment from the home directory of another member! This wasn’t even that long ago. Around 2010. It was a nice student union.
- don-code 2y ago
  Indeed, I've been having this conversation with the junior engineers on my team. UNIX was designed for the days when computers - and the operating system - were shared resources, and each individual's permissions to it had to be strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance, especially where our applications in production are all single processes deployed in containers. But anyway, it at least gives them the context on why they're working on these projects to not make containers run as root.
  - jorvi 2y ago
    > strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance Not so. Multiple users make perfect sense for a household tablet or a gaming PC / console shared between siblings. Concurrent access is rarely a thing anymore, but serial access is a very common use case.
    - weitendorf 2y ago
      These days if the device is expected to be ~always internet-connected (increasingly a safe bet) it probably makes more sense for both the developers and users to handle multiple users with a remote identity provider (email, individual account for the particular service, etc.) rather than implementing identity per-device. I'm pretty sure gaming consoles have had support for this for a long time (at least since xbox 360?), and Microsoft is moving towards this model with Windows. And Microsoft Active Directory is 25 years old. I personally find it annoying to be forced to use remote identity for devices used by me exclusively, but it makes a lot of sense for shared devices. I'm pretty sure a large portion of people sharing one kind of device would also using be using other devices for the same purpose (eg a kid with divorced parents, a school or office or library with laptops available to be checked out, a tablet used for logistics), so they'd want their data to sync across devices. Handling identity per-device works for local-only files, but also makes it so users need to manually and deliberately configure some kind of syncing if they really do want those files to be available across devices, which to technical people is NBD, but most users aren't technical. It's also just a more secure way to manage data in a corporate setting. Of course, not every shared device can be expected to always be connected to the internet, some people don't want to back things up remotely for a variety of reasons, and this doesn't matter as much for devices only used by one person. In practice I personally hate how much Microsoft begs and nudges you into this setup even if you're the only one using your computer. But for the majority of users in the majority of cases, remote identity is probably better than local identity, and in the absence of internet it can always fail-open to local identity.
- weitendorf 2y ago
  I think this is underrated as a design flaw for how Linux tends to be used in 2024. At its most benign it's an anachronism and potential source of complexity, as its worst it's a major source of security vulnerabilities and unintended behavior (eg linux multitenancy was designed for two people in the same lab sharing a server, not for running completely untrusted workloads at huge scale, so it doesn't really implement resource fairness or protect against DoS well). I haven't had a chance to try it out but this is why I think Talos linux (https://www.talos.dev/ https://www.talos.dev/) is a step in the right direction for Linux as it is used for cloud/servers. Though personally I think multitenancy esp. regarding containerized applications/cgroups is a bigger problem and I don't know if they're addressing that.
  - mikepurvis 2y ago
    My impression was that all the hosted k8s providers are doing multitenancy with if not full per-customer VMs, at least additional abstractions like gVisor. Are there some that aren't? Or are you referring here more to untrusted/shared in the sense of platforms like Github Actions just running everyone's different loads on the same pool of kernels?
    - weitendorf 2y ago
      Right, I'm talking about shared-kernel multitenancy. Shared-kernel multitenancy isn't just about reducing the OS overhead from host + one or more VMs (or sandboxes) to just a single host, it's also about not having to continually start and stop virtual machines/sandboxes, which introduces its own resource overhead as well as a latency hit (which essentially always coincides with resource pressure from increased usage, since that's why you're scaling up) every time it's done. Also, even VMs and sandboxes don't really protect against DoS/resource fairness/noisy neighbor problems that well in many cases. Why does this matter? Incurring kernel/sandbox boot overhead on cold start/scaling makes it so that services have to over-provision resources to account for potential future resource needs. This wastes a lot of compute. I also think it's incredibly wasteful for companies to manage their own K8s cluster (if K8s supported multitenancy you'd probably want only one instance per-datacenter, and move whatever per-cluster settings people depend on to per-service. This is also much closer to "how Google does things" and why I think Kubernetes sucks to use compared to Borg), again because of all the stranded compute, and also because of the complexity of setting it up and managing it - but without shared-kernel multitenancy, multi-tenant K8s has to employ a lot of complicated workarounds in userspace. Or you can use a serverless product, ie pay for someone else's implementation of those workarounds, and still suffer some of the resource/latency overhead from lack of shared kernel multitenancy. This is one of the problems I want to address with my company BTW, but it would take years if not decades to get there, which is why I'm starting with something else.
- throw0101d 2y ago
  > 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! Except if you're on a team of sysadmins running a fleet of systems, either a whole bunch of cattle and/or numerous pets. There are numerous occasions that I have to SSH to look at something on an individual system, and it's best practice to go in as yourself and then sudo-to-root if you need to poke into privileged parts. App folks can also be allowed in unprivileged and become the service users if needed. The fact that sudo can hook into LDAP also means we can centralize privilege escalations with groups and (particular) hosts. Lots of HPC out there as well that is multi-user.
  - thousand_nights 2y ago
    > Except if you're on a team of sysadmins running a fleet of systems not trying to be rude but this doesn't sound like "most people"
    - Daneel_ 2y ago
      Interesting comment actually. I would have assumed that the vast majority of people using Linux are still sysadmins in small and large companies - this is certainly my personal experience. I wonder how many home users there are versus systems managed by sysadmins. I would still think there’s more in the corporate world, while I would think the opposite for Windows.
      - Swizec 2y ago
        > I wonder how many home users there are versus systems managed by sysadmins Isn’t Android the most popular Linux distro these days? Probably also most TV set-top boxes and other IoT devices
        kelnos 2y ago
        And ironically an Android user (well, an Android user that uses the "official" OS image from the device's manufacturer) is not the system administrator of their phone/tablet, unless they essentially break into it, or install a different OS image designed to allow root access.
- guappa 2y ago
  Except if you've ever been to university or work with HPC or a number of other fields.
- kube-system 2y ago
  The vast majority of linux users use linux on a phone and have never opened a terminal. Most people who use 'sudo' in a terminal are professionals or academics who commonly do or have used linux in a multi-user environment.
alwayslikethis 2y ago
I thought this is about the other warning, which has since been removed: https://github.com/sudo-project/sudo/commit/6aa320c96a37613663e8de4c275bd6c490466b01 https://github.com/sudo-project/sudo/commit/6aa320c96a376136...
- b112 2y ago
  What's with all the F responses? I appearedly missed this fad.
  - krispyfi 2y ago
    https://knowyourmeme.com/memes/f-in-the-chat https://knowyourmeme.com/memes/f-in-the-chat
    - b112 2y ago
      Thanks
ggm 2y ago
Back in the 90s we were told ostentatiously to include "unauthorised access is not permitted" to the login prompt. Why? Because the login prompt said "please login:" and this was being read by some bush lawyer as an invitation to connect, and therefore would impede a case if we had a hacker login with a stolen password. I think it was founded on urban myth, but I assure you this is what we were told to do: add text to make it plain, the invitation was to legitemate users only. I felt the sudo warning was in the same spirit.
- horeszko 2y ago
  My networking instructor still suggests this today when configuring the login for routers and switches
  - sigmoid10 2y ago
    Perhaps it is useful for countries that still don't have any real computer crime laws? Because in most western nations it would be totally pointless.
    - bubblethink 2y ago
      No, the US is the main country that loves these messages. Have you seen the size of universities or the government ? It's just clerical staff doing make believe work. Go to any .gov website. They'll throw up a wall of bs before you log in (e.g., https://ttp.dhs.gov/ https://ttp.dhs.gov/ ).
      - thrw42A8N 2y ago
        Sounds like you have never been to Europe. Here they make you actually sign (as in pen and paper) this stuff before they give you access.
        vundercind 2y ago
        I used to read an Eastern European world traveler photoblogger who’d been to damn near every country (even a lot that most folks from even semi-developed countries would consider far too dangerous or boring to be worth going out of your way to visit—he’d surely been to at least 150 countries, several more than once) and according to him the specific behavior of posting regulations and signs all over the place is practiced nowhere as much as the US, with only Australia coming sort-of close. I was a bit blind to it, being a born American, but once he pointed it out I can’t un-see it. The land of the free really does love posting regulations everywhere.
deleted 2y ago
[deleted]
osigurdson 2y ago
"This incident will be reported" Surely they were thinking at the time that the user was a student.
- deleted 2y ago
  [deleted]
- fsckboy 2y ago
  the incidents were reported, email to root. Would you prefer that you get narc'ed silently?
godelski 2y ago
# /etc/sudoers.d/99-insults --------------------------- Defaults insults Thank me later. The number just defines load order (99 being last), you can use whatever you want. You may also want Defaults env_keep += "EDITOR SYSTEMD_EDITOR"
tonymet 2y ago
Pretty wild that sudo is still the most common authorization framework for linux.
- unit149 2y ago
  Sudo will temporarily get you in su, whereas the cu command calls another user within the original shell. Designating kernel privileges within an instantiation works in the absence of a w-r permissions setting scheme for designating cron tasks + programs.
  - ricktdotorg 2y ago
    s/cu /su /g
perbu 2y ago
sudo also had the ominous warning, "This incident will be reported!" when you fail to authorize the request. ofc, it just just logged.
- deadbunny 2y ago
  I remember my first linux admin gig and mistyping my password when using sudo then getting an email about it a few seconds later. After years of home linux use this amused me and was like "oh, so that's what happens when things are configured properly".
  - BenjiWiebe 2y ago
    It mails the root user by default.
goodpoint 2y ago
It's about time we remove it.
smidgeon 2y ago
My first experience of Unix was on a dumb terminal on a university AIX (?) machine, I had heard that "man" was how you got to the documentation, so duly typed "man", the resulting Apropos what? made me laugh out loud, and the others in the room gave me a funny look.
kawsper 2y ago
It's interesting how messages gets their own life. I was building a user-impersonation system, and it allowed a power-admin to login as another user to change their settings and to help them. When you signed in as the user it said: > You are now signed in as User\##{user_id}, behave nicely ;-) and when you switched back to your admin it said: > You are now signed back in as Admin\##{admin_id}, wreak havoc! ;-) I met with a former colleague years later, and he still referred to the wreak havoc message that I didn't think about for more than 10 seconds, but I had installed that in his brain and it lived there as a memory of that company and that system.
- AlienRobot 2y ago
  You infected him with a mind virus. He's going to tell about that message to other people, who will tell about it to others. Before you know it, it's gone viral.
- ochrist 2y ago
  Oh. It sounds like you were The Bastard Operator From Hell: https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell
steinuil 2y ago
FYI, you can turn this off by adding "Defaults lecture = never" to /etc/sudoers. In Nix: { security.sudo.extraConfig = '' Defaults lecture = never ''; } Or you could also set it to "always" to annoy your users :^)
technothrasher 2y ago
I was at the University of Rochester as an undergrad working with the computing center's Unix Group when sudo added this message. We quickly modified our local version to read, "Friends don't let friends su drunk."
TacticalCoder 2y ago
I've got no "sudo" command on my main Linux workstation: the only way to log in as root is by using a Yubikey, from another computer, which is on a private LAN only shared between my workstation and my "terminal" (an old laptop which I know only use as some kind of remote console/terminal to log in as root on my workstation). So on my workstation I allow ssh root login, but only using keys (no password) (and only on that private LAN). Getting in as root without the Yubikey means finding a remote exploit in sshd. And in all my containers: no sudo command installed either. As you may have guessed I'm not a big fan of sudo.
- mixmastamyk 2y ago
  Is installing sudo in a container common? Don’t think I’ve ever seen that.
- greggyb 2y ago
  Any reason not to run SSH on localhost only? This way there would be no network requirement whatsoever. I am not trying to criticize, but am just curious what you gain by having this access split across two machines?
- kccqzy 2y ago
  A long time ago I also wasn't a fan of sudo so I used SSH only (password authentication from localhost). Eventually I stopped caring and stopped having strong opinions about sudo anymore.

158 points by Boogie_Man 2y ago

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-bellovins-retirement-talk.html https://www.schneier.com/blog/archives/2024/11/steve-bellovi...

xyse53 2y ago
https://en.m.wikipedia.org/wiki/Evi_Nemeth https://en.m.wikipedia.org/wiki/Evi_Nemeth was part of the early development of sudo. I did a double take years ago running "The Woz Lab" at CU Boulder, reading the sudoers man page and seeing the 128.138 address space in the examples that I was managing subnets of.

pram 2y ago

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!

amelius 2y ago
Yeah, the threat model has shifted in recent years from other users to applications downloaded over the internet. It is a pity that OS security has not caught up.
Boogie_Man 2y ago
I often give myself stern talking tos when I made ignorant sysadmin decisions
- 0xbadcafebee 2y ago
  I put myself on a PIP for losing my backups. If I'm not careful I might fire my ass
quotemstr 2y ago
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!
- monsieurbanana 2y ago
  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.
- dhosek 2y ago
  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.
  - quotemstr 2y ago
    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.
  - alwayslikethis 2y ago
    I don't think privilege escalation is a big concern on most personal systems. If you run any malicious code, even unprivileged, you're basically already screwed anyways since the code can access all of your home, upload it, delete/encrypt it, etc. https://xkcd.com/1200/ https://xkcd.com/1200/
II2II 2y ago
... 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.)
- codetrotter 2y ago
  I was member of a student union at my university, for people interested in computers. We had desktop computers and servers that belonged to the student union, and member students would eventually be granted sudo privileges if they had a reason to need it. When they gave me and my friends sudo privileges they told us basically the sudo lecture. Use it for good, don’t snoop in other students files, and be careful to not break stuff. They even had a real-life story of their own, about one past member that was kicked out of the union because he had used his sudo privileges to read solutions to an assignment from the home directory of another member! This wasn’t even that long ago. Around 2010. It was a nice student union.
don-code 2y ago
Indeed, I've been having this conversation with the junior engineers on my team. UNIX was designed for the days when computers - and the operating system - were shared resources, and each individual's permissions to it had to be strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance, especially where our applications in production are all single processes deployed in containers. But anyway, it at least gives them the context on why they're working on these projects to not make containers run as root.
- jorvi 2y ago
  > strictly defined and controlled. Nowadays, we have users as a vestige, and partially as a hindrance Not so. Multiple users make perfect sense for a household tablet or a gaming PC / console shared between siblings. Concurrent access is rarely a thing anymore, but serial access is a very common use case.
  - weitendorf 2y ago
    These days if the device is expected to be ~always internet-connected (increasingly a safe bet) it probably makes more sense for both the developers and users to handle multiple users with a remote identity provider (email, individual account for the particular service, etc.) rather than implementing identity per-device. I'm pretty sure gaming consoles have had support for this for a long time (at least since xbox 360?), and Microsoft is moving towards this model with Windows. And Microsoft Active Directory is 25 years old. I personally find it annoying to be forced to use remote identity for devices used by me exclusively, but it makes a lot of sense for shared devices. I'm pretty sure a large portion of people sharing one kind of device would also using be using other devices for the same purpose (eg a kid with divorced parents, a school or office or library with laptops available to be checked out, a tablet used for logistics), so they'd want their data to sync across devices. Handling identity per-device works for local-only files, but also makes it so users need to manually and deliberately configure some kind of syncing if they really do want those files to be available across devices, which to technical people is NBD, but most users aren't technical. It's also just a more secure way to manage data in a corporate setting. Of course, not every shared device can be expected to always be connected to the internet, some people don't want to back things up remotely for a variety of reasons, and this doesn't matter as much for devices only used by one person. In practice I personally hate how much Microsoft begs and nudges you into this setup even if you're the only one using your computer. But for the majority of users in the majority of cases, remote identity is probably better than local identity, and in the absence of internet it can always fail-open to local identity.
weitendorf 2y ago
I think this is underrated as a design flaw for how Linux tends to be used in 2024. At its most benign it's an anachronism and potential source of complexity, as its worst it's a major source of security vulnerabilities and unintended behavior (eg linux multitenancy was designed for two people in the same lab sharing a server, not for running completely untrusted workloads at huge scale, so it doesn't really implement resource fairness or protect against DoS well). I haven't had a chance to try it out but this is why I think Talos linux (https://www.talos.dev/ https://www.talos.dev/) is a step in the right direction for Linux as it is used for cloud/servers. Though personally I think multitenancy esp. regarding containerized applications/cgroups is a bigger problem and I don't know if they're addressing that.
- mikepurvis 2y ago
  My impression was that all the hosted k8s providers are doing multitenancy with if not full per-customer VMs, at least additional abstractions like gVisor. Are there some that aren't? Or are you referring here more to untrusted/shared in the sense of platforms like Github Actions just running everyone's different loads on the same pool of kernels?
  - weitendorf 2y ago
    Right, I'm talking about shared-kernel multitenancy. Shared-kernel multitenancy isn't just about reducing the OS overhead from host + one or more VMs (or sandboxes) to just a single host, it's also about not having to continually start and stop virtual machines/sandboxes, which introduces its own resource overhead as well as a latency hit (which essentially always coincides with resource pressure from increased usage, since that's why you're scaling up) every time it's done. Also, even VMs and sandboxes don't really protect against DoS/resource fairness/noisy neighbor problems that well in many cases. Why does this matter? Incurring kernel/sandbox boot overhead on cold start/scaling makes it so that services have to over-provision resources to account for potential future resource needs. This wastes a lot of compute. I also think it's incredibly wasteful for companies to manage their own K8s cluster (if K8s supported multitenancy you'd probably want only one instance per-datacenter, and move whatever per-cluster settings people depend on to per-service. This is also much closer to "how Google does things" and why I think Kubernetes sucks to use compared to Borg), again because of all the stranded compute, and also because of the complexity of setting it up and managing it - but without shared-kernel multitenancy, multi-tenant K8s has to employ a lot of complicated workarounds in userspace. Or you can use a serverless product, ie pay for someone else's implementation of those workarounds, and still suffer some of the resource/latency overhead from lack of shared kernel multitenancy. This is one of the problems I want to address with my company BTW, but it would take years if not decades to get there, which is why I'm starting with something else.
throw0101d 2y ago
> 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! Except if you're on a team of sysadmins running a fleet of systems, either a whole bunch of cattle and/or numerous pets. There are numerous occasions that I have to SSH to look at something on an individual system, and it's best practice to go in as yourself and then sudo-to-root if you need to poke into privileged parts. App folks can also be allowed in unprivileged and become the service users if needed. The fact that sudo can hook into LDAP also means we can centralize privilege escalations with groups and (particular) hosts. Lots of HPC out there as well that is multi-user.
- thousand_nights 2y ago
  > Except if you're on a team of sysadmins running a fleet of systems not trying to be rude but this doesn't sound like "most people"
  - Daneel_ 2y ago
    Interesting comment actually. I would have assumed that the vast majority of people using Linux are still sysadmins in small and large companies - this is certainly my personal experience. I wonder how many home users there are versus systems managed by sysadmins. I would still think there’s more in the corporate world, while I would think the opposite for Windows.
    - Swizec 2y ago
      > I wonder how many home users there are versus systems managed by sysadmins Isn’t Android the most popular Linux distro these days? Probably also most TV set-top boxes and other IoT devices
      - kelnos 2y ago
        And ironically an Android user (well, an Android user that uses the "official" OS image from the device's manufacturer) is not the system administrator of their phone/tablet, unless they essentially break into it, or install a different OS image designed to allow root access.
guappa 2y ago
Except if you've ever been to university or work with HPC or a number of other fields.
kube-system 2y ago
The vast majority of linux users use linux on a phone and have never opened a terminal. Most people who use 'sudo' in a terminal are professionals or academics who commonly do or have used linux in a multi-user environment.

alwayslikethis 2y ago

I thought this is about the other warning, which has since been removed: https://github.com/sudo-project/sudo/commit/6aa320c96a37613663e8de4c275bd6c490466b01 https://github.com/sudo-project/sudo/commit/6aa320c96a376136...

b112 2y ago
What's with all the F responses? I appearedly missed this fad.
- krispyfi 2y ago
  https://knowyourmeme.com/memes/f-in-the-chat https://knowyourmeme.com/memes/f-in-the-chat
  - b112 2y ago
    Thanks

ggm 2y ago

Back in the 90s we were told ostentatiously to include "unauthorised access is not permitted" to the login prompt. Why? Because the login prompt said "please login:" and this was being read by some bush lawyer as an invitation to connect, and therefore would impede a case if we had a hacker login with a stolen password. I think it was founded on urban myth, but I assure you this is what we were told to do: add text to make it plain, the invitation was to legitemate users only. I felt the sudo warning was in the same spirit.

horeszko 2y ago
My networking instructor still suggests this today when configuring the login for routers and switches
- sigmoid10 2y ago
  Perhaps it is useful for countries that still don't have any real computer crime laws? Because in most western nations it would be totally pointless.
  - bubblethink 2y ago
    No, the US is the main country that loves these messages. Have you seen the size of universities or the government ? It's just clerical staff doing make believe work. Go to any .gov website. They'll throw up a wall of bs before you log in (e.g., https://ttp.dhs.gov/ https://ttp.dhs.gov/ ).
    - thrw42A8N 2y ago
      Sounds like you have never been to Europe. Here they make you actually sign (as in pen and paper) this stuff before they give you access.
      - vundercind 2y ago
        I used to read an Eastern European world traveler photoblogger who’d been to damn near every country (even a lot that most folks from even semi-developed countries would consider far too dangerous or boring to be worth going out of your way to visit—he’d surely been to at least 150 countries, several more than once) and according to him the specific behavior of posting regulations and signs all over the place is practiced nowhere as much as the US, with only Australia coming sort-of close. I was a bit blind to it, being a born American, but once he pointed it out I can’t un-see it. The land of the free really does love posting regulations everywhere.

deleted 2y ago

[deleted]

osigurdson 2y ago

"This incident will be reported" Surely they were thinking at the time that the user was a student.

deleted 2y ago
[deleted]
fsckboy 2y ago
the incidents were reported, email to root. Would you prefer that you get narc'ed silently?

godelski 2y ago

# /etc/sudoers.d/99-insults --------------------------- Defaults insults Thank me later. The number just defines load order (99 being last), you can use whatever you want. You may also want Defaults env_keep += "EDITOR SYSTEMD_EDITOR"

tonymet 2y ago

Pretty wild that sudo is still the most common authorization framework for linux.

unit149 2y ago
Sudo will temporarily get you in su, whereas the cu command calls another user within the original shell. Designating kernel privileges within an instantiation works in the absence of a w-r permissions setting scheme for designating cron tasks + programs.
- ricktdotorg 2y ago
  s/cu /su /g

perbu 2y ago

sudo also had the ominous warning, "This incident will be reported!" when you fail to authorize the request. ofc, it just just logged.

deadbunny 2y ago
I remember my first linux admin gig and mistyping my password when using sudo then getting an email about it a few seconds later. After years of home linux use this amused me and was like "oh, so that's what happens when things are configured properly".
- BenjiWiebe 2y ago
  It mails the root user by default.

goodpoint 2y ago

It's about time we remove it.

smidgeon 2y ago

My first experience of Unix was on a dumb terminal on a university AIX (?) machine, I had heard that "man" was how you got to the documentation, so duly typed "man", the resulting Apropos what? made me laugh out loud, and the others in the room gave me a funny look.

kawsper 2y ago

It's interesting how messages gets their own life. I was building a user-impersonation system, and it allowed a power-admin to login as another user to change their settings and to help them. When you signed in as the user it said: > You are now signed in as User\##{user_id}, behave nicely ;-) and when you switched back to your admin it said: > You are now signed back in as Admin\##{admin_id}, wreak havoc! ;-) I met with a former colleague years later, and he still referred to the wreak havoc message that I didn't think about for more than 10 seconds, but I had installed that in his brain and it lived there as a memory of that company and that system.

AlienRobot 2y ago
You infected him with a mind virus. He's going to tell about that message to other people, who will tell about it to others. Before you know it, it's gone viral.
ochrist 2y ago
Oh. It sounds like you were The Bastard Operator From Hell: https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell https://en.wikipedia.org/wiki/Bastard_Operator_From_Hell

steinuil 2y ago

FYI, you can turn this off by adding "Defaults lecture = never" to /etc/sudoers. In Nix: { security.sudo.extraConfig = '' Defaults lecture = never ''; } Or you could also set it to "always" to annoy your users :^)

technothrasher 2y ago

I was at the University of Rochester as an undergrad working with the computing center's Unix Group when sudo added this message. We quickly modified our local version to read, "Friends don't let friends su drunk."

TacticalCoder 2y ago

I've got no "sudo" command on my main Linux workstation: the only way to log in as root is by using a Yubikey, from another computer, which is on a private LAN only shared between my workstation and my "terminal" (an old laptop which I know only use as some kind of remote console/terminal to log in as root on my workstation). So on my workstation I allow ssh root login, but only using keys (no password) (and only on that private LAN). Getting in as root without the Yubikey means finding a remote exploit in sshd. And in all my containers: no sudo command installed either. As you may have guessed I'm not a big fan of sudo.

mixmastamyk 2y ago
Is installing sudo in a container common? Don’t think I’ve ever seen that.
greggyb 2y ago
Any reason not to run SSH on localhost only? This way there would be no network requirement whatsoever. I am not trying to criticize, but am just curious what you gain by having this access split across two machines?
kccqzy 2y ago
A long time ago I also wasn't a fan of sudo so I used SSH only (password authentication from localhost). Eventually I stopped caring and stopped having strong opinions about sudo anymore.