4 ms·

Or you set up your system so mail for root gets redirected to an smtp server with an actual inbox read by actual people

jamal-kumar 3y ago
Yeah, I kind of lament them removing this warning if I'm going to be honest. It feels like something such as that should be more common best practice. Of course decent log collection/monitoring should also be able to catch authlog stuff and alert accordingly and I'm sure most organizations rely on solutions like that instead of letting things get lost in email
- stefncb 3y ago
  It's only removed if sudo doesn't send mail. It still warns if it's relevant.
  - electroly 3y ago
    This is a pretty short diff and it clearly does NOT do that, unless you're saying they went back later in another commit to add this. They removed the message in all situations. The string "This incident will be reported" has been removed from the source code; it could not possibly print that message now.
    - simse 3y ago
      The warning is added back here: https://github.com/sudo-project/sudo/commit/9757d29a24ac1872872cf09757b0439c54089707 https://github.com/sudo-project/sudo/commit/9757d29a24ac1872...
  - fafqg 3y ago
    This doesn't seem to be correct.
  - freedomben 3y ago
    Is there more to the change than the linked commit? Because if not, looking at the code change I don't see how you could possibly be correct. There is no additional logic/branching that could be checking whether sudo sends mail or not, just a string change.
    - TaylorAlexander 3y ago
      It was added back in a later commit but only prints if the mail is configured.
      - freedomben 3y ago
        Nice, thanks that's very useful info
  - bo0tzz 3y ago
    This is correct, and was added back a few weeks later in https://github.com/sudo-project/sudo/commit/9757d29a24ac1872872cf09757b0439c54089707 https://github.com/sudo-project/sudo/commit/9757d29a24ac1872...
  - can16358p 3y ago
    Isn't it leaking detail about internal policy about whether incorrect sudoing is getting reported or not though?
- asveikau 3y ago
  I feel like that warning comes right out of the era of multi-user machines with unprivileged shell accounts. That era is largely gone. Today, someone, possibly a less knowledgeable user, runs sudo on their single user laptop that they completely own outright, and may get confused who they're being "reported" to.
  - jamal-kumar 3y ago
    Funny if you live in a free country Potentially terrifying if you don't
  - wkat4242 3y ago
    To themselves of course. That's pretty clear. But there is a renewed focus on corporate laptops to remove admin rights on windows. Not really because the user is not being trusted, but because malware has a lot more options for bypassing EDR/antimalware and persistence when it runs with admin rights. I'm sure this will come to Linux too at some point.
ctoth 3y ago
Completely this, I was so confused by OP because naturally this is how my playbooks configure my systems.
- jamal-kumar 3y ago
  I think this is mostly relevant to how confused and sometimes downright mortified it makes new users of sudo when they encounter it In other words, don't think well-configured ansible playbooks are most people's first exposure to linux although it does sound like you're doing things right which is nice to hear
jimmaswell 3y ago
I was surprised to start getting emails about my cron tasks once I set up my mail server. It's neat.
- prmoustache 3y ago
  I've always felt it was a very bad practice not to do it. In a lot of companies but one they avoided it for fear of receiving emails. On that only company that did it, we made sure that mailbox was clean by actually having a look when cron scripts were crapping out or when users failed sudo repeatedly and contacted the users. It was a much better housekeeping than log on a box and see there are hundreds of unread emails but dismissing it like most do.
  - evilspammer 3y ago
    I think it's a fear of _sending_ emails. You could accidentally trigger a cronjob that sends a bunch of emails and gets you put on spam filters. Error reporting for cron is, of course, important; but the builtin email reporting is best used for the local machine/network. A more flexible and robust solution calls out to an API that handles transactional emails/push notifications with debouncing, escalation policies, etc.
- hiepph 3y ago
  Well, it depends! Because what you need to see more often is errors. You don't want successful notifications "spam" more often than error notifications.

Yeah, I kind of lament them removing this warning if I'm going to be honest. It feels like something such as that should be more common best practice. Of course decent log collection/monitoring should also be able to catch authlog stuff and alert accordingly and I'm sure most organizations rely on solutions like that instead of letting things get lost in email

stefncb 3y ago
It's only removed if sudo doesn't send mail. It still warns if it's relevant.
- electroly 3y ago
  This is a pretty short diff and it clearly does NOT do that, unless you're saying they went back later in another commit to add this. They removed the message in all situations. The string "This incident will be reported" has been removed from the source code; it could not possibly print that message now.
  - simse 3y ago
    The warning is added back here: https://github.com/sudo-project/sudo/commit/9757d29a24ac1872872cf09757b0439c54089707 https://github.com/sudo-project/sudo/commit/9757d29a24ac1872...
- fafqg 3y ago
  This doesn't seem to be correct.
- freedomben 3y ago
  Is there more to the change than the linked commit? Because if not, looking at the code change I don't see how you could possibly be correct. There is no additional logic/branching that could be checking whether sudo sends mail or not, just a string change.
  - TaylorAlexander 3y ago
    It was added back in a later commit but only prints if the mail is configured.
    - freedomben 3y ago
      Nice, thanks that's very useful info
- bo0tzz 3y ago
  This is correct, and was added back a few weeks later in https://github.com/sudo-project/sudo/commit/9757d29a24ac1872872cf09757b0439c54089707 https://github.com/sudo-project/sudo/commit/9757d29a24ac1872...
- can16358p 3y ago
  Isn't it leaking detail about internal policy about whether incorrect sudoing is getting reported or not though?
asveikau 3y ago
I feel like that warning comes right out of the era of multi-user machines with unprivileged shell accounts. That era is largely gone. Today, someone, possibly a less knowledgeable user, runs sudo on their single user laptop that they completely own outright, and may get confused who they're being "reported" to.
- jamal-kumar 3y ago
  Funny if you live in a free country Potentially terrifying if you don't
- wkat4242 3y ago
  To themselves of course. That's pretty clear. But there is a renewed focus on corporate laptops to remove admin rights on windows. Not really because the user is not being trusted, but because malware has a lot more options for bypassing EDR/antimalware and persistence when it runs with admin rights. I'm sure this will come to Linux too at some point.

ctoth 3y ago

Completely this, I was so confused by OP because naturally this is how my playbooks configure my systems.

jamal-kumar 3y ago
I think this is mostly relevant to how confused and sometimes downright mortified it makes new users of sudo when they encounter it In other words, don't think well-configured ansible playbooks are most people's first exposure to linux although it does sound like you're doing things right which is nice to hear

jimmaswell 3y ago

I was surprised to start getting emails about my cron tasks once I set up my mail server. It's neat.

prmoustache 3y ago
I've always felt it was a very bad practice not to do it. In a lot of companies but one they avoided it for fear of receiving emails. On that only company that did it, we made sure that mailbox was clean by actually having a look when cron scripts were crapping out or when users failed sudo repeatedly and contacted the users. It was a much better housekeeping than log on a box and see there are hundreds of unread emails but dismissing it like most do.
- evilspammer 3y ago
  I think it's a fear of _sending_ emails. You could accidentally trigger a cronjob that sends a bunch of emails and gets you put on spam filters. Error reporting for cron is, of course, important; but the builtin email reporting is best used for the local machine/network. A more flexible and robust solution calls out to an API that handles transactional emails/push notifications with debouncing, escalation policies, etc.
hiepph 3y ago
Well, it depends! Because what you need to see more often is errors. You don't want successful notifications "spam" more often than error notifications.