Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've never understood the need for sudo(1) on single-user, physical machines: I keep a root shell (su(1)) around for admin tasks, and it's always been sufficient.


Everything I run with sudo is logged so I know how I messed up.

Nothing worse than ansible with its “sudo /tmp/whatever.sh” which hides what it’s doing.


> Everything I run with sudo is logged so I know how I messed up.

FWIW, shells have a (configurable) history file. I'm not sure how it compares to sudo's logging though. I also personally perform little day to day admin tasks (I don't have as much time nor interest to toy around as I used to, and my current setup has been sufficient for about a decade).

> Nothing worse than ansible with its “sudo /tmp/whatever.sh” which hides what it’s doing.

That's a nightmare indeed; for sensitive and complex-enough tasks requiring a script, those scripts should at least be equipped with something as crude as a ``log() { printf ... | tail $logfile`` }.


Its just maybe easier way to not have to go to the root shell.


Makes sense (I keep one warm in a tmux, two shortcuts away at most, so it never occurred to me).


One password is easier than two and it feels weird to use the same password for both accounts. About half of my sudo invocations are 'sudo su' lmao.


You could probably save a process with `sudo -i`


Slightly less convienent to type.


You're entering your own accounts password, not root, when you use sudo. It's a security measure to prove our shell hasn't been hijacked and to make you pause and acknowledge your running a command that may affect the entire system.

You can also disable it in the sudoers file.


> it feels weird to use the same password for both accounts

I'm not sure different passwords adds more protection for single-user machines, especially when sudo(1) can spawn root shells!


of mine are sudo bash.


Scripting.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: