Talk:Sudo

Unclear intention of the section discussing hostnames

Hi, in the section "Example entries" I stumbled over this sentence: "To allow a user to run all commands as any user but only the machine with hostname HOST_NAME:" Is this intended to be saying "...on the machine...", like physically, not by ssh for example? Would be great to clarify this! Kay94 (talk) 15:03, 28 July 2017 (UTC)kay94

As of this writing, 3.4 example entries has

To allow a user to run all commands as any user but only on the machine with hostname HOST_NAME

As for remote machines, this is discussed at the introductory and -h host sections of sudo(8) § DESCRIPTION, as well as at sudo(8) § Plugins. It is my understanding that with the default sudo package, using sudo on a machine connected by ssh requires appropriate sudo configuration on the remote machine. Regid (talk) 21:54, 12 March 2023 (UTC)

On not requiring password at console

I don't want to type my password at the console. Nobody else has access to my console unless they break into my house, and if they do that they can just take my computer. I do want to type my password if I'm ssh'd in, because if somebody breaks into my account somehow I'd just as soon they not also have root access. So what exactly is wrong with putting this in pam:

auth	sufficient	pam_succeed_if.so	tty = /dev/tty1

Not that it really matters, for the reasons stated above, but don't forget this won't give sudo access to anyone logged into the console; you still have to be in sudoers.

I put something to this effect in the article, and was reverted. Please let me know what I'm missing. --Chowbok (talk) 22:04, 19 February 2018 (UTC)

Of course use it if you want. But I don't see why it should be listed on the wiki without any security implications - for example a warning quite similar to the one in sudo#Disable_per-terminal_sudo would be appropriate. Also it does not seem very useful to me, since any graphical terminal uses pty rather than tty and you can just as well log in as root to the console to do the administrative things (there is also sudo -s). -- Lahwaacz (talk) 23:28, 19 February 2018 (UTC)

Undo revision 543841

What do you mean by "it's not necessary"? I followed the examples on a fresh arch system and was told by another arch user I had to logout for the changes to take effect. And that was correct.

Johnjay79 (talk) 10:07, 27 September 2018 (UTC)

You may have needed that because of some things other than sudo. I have no idea what you did on your fresh system. -- Lahwaacz (talk) 10:21, 27 September 2018 (UTC)

Okay, can you give me a list of steps I should do to reproduce the problem to your satisfaction with a fresh system? Note I still have to run dhcpcd in order to get an internet connection to download sudo as it does not come installed. Johnjay79 (talk) 10:41, 27 September 2018 (UTC)

What problem? I have no idea what your system looks like or what you're trying to do. Also, I have no idea how you could have played with sudo before adding the warning, but still not having it installed. -- Lahwaacz (talk) 10:51, 27 September 2018 (UTC)

Disable root login, missing infos ?

I recently installed sudo and disabled root login. When launching graphical apps that require root access (gparted, partitionmanager, etc.) I was still prompted for the root password.

Of course I found this page and the part about disabling root login and configuring kdesu. As I am suing KDE, I thought I was good, but I was still prompted for the root password.

Looking deeper into it, I found that running kdesu <command> did prompt me for my own password, and that I was still prompted for root password because it was polkit (and not kdesu) prompting me for root password.

In the end, I solved my problem by adding the sudo group to the list of polkit admins:

polkit.addAdminRule(function(action, subject) {
    return ["unix-group:sudo"];
});

So I feel this wiki is incomplete and we need to add a section (4.7.2 ?) that explains that one might want to add a polkit rule when disabling root login.

However, I am not sure this is a best practice and do not know enough about polkit to write this part myself; I do not know the difference between using polkit ".rules" files like it is documented in Arch Wiki and using polkit localauthority ".conf" files like it is done in Ubuntu.

BTerrier (talk) 21:01, 5 April 2020 (UTC)

Where are the sudo logs?

In the beginning of this article, right before the TOC, it is written "sudo logs all commands and failed access attempts for security auditing". But there's no mention of these logs. Where is it?

—This unsigned comment is by Heitorpb (talk) 02:31, 16 June 2021. Please sign your posts with ~~~~!

It is in the systemd journal. — Lahwaacz (talk) 05:59, 16 June 2021 (UTC)

sudoedit

Any reason why a recent modification removes sudoedit and prefers sudo -e ? The examples in sudo(8) use sudoedit and it's a more convenient way to use it. Waiting for ideas, otherwise I'll revert it in a couple days.

-- Cvlc (talk) 12:50, 4 December 2022 (UTC)

No particular reason. The original content used sudo -e and I just followed the suit. I am ok with either option. Just don’t describe both: it produces unnecessary clutter. --Mpan (talk) 00:37, 6 December 2022 (UTC)

Remove alias recommendation in "Reduce the number of times you have to type a password"?

To my knowledge (and from some testing), running sudo with a command as normal already refreshes the password timeout, so running sudo -v beforehand has no effect. Hence, I believe that the recommendation to use the alias should just be removed. Anyone have additional information or opinions on this before I delete that part? MithicSpirit (talk) 19:15, 5 October 2023 (UTC)

Agree. It's described in man sudo and man sudoers. timestamp_timeout counts from last use. -v can be used to renew without running a real command, but kind of pointless because can run something like sudo ls or sudo true. Might be useful to keep -K to revoke immediately. Xiota (talk) 09:27, 17 November 2023 (UTC)