1. Forum
  2. Usenet
  3. LINUX.DEBIAN.USER

  • Re: Debian 12.9 and use of sudo for regular accounts

    From Nicolas George@21:1/5 to All on Thu Feb 20 23:50:01 2025
    Jeffrey Walton (HE12025-02-20):
    and members of sudo can run any command.

    Is it because of this last line:

    root ALL=(ALL:ALL) ALL

    sudo ALL=(ALL:ALL) ALL

    ? But does it mean the previous one gives sudo privileges to all members
    of the root group? Or is it that the last line gives sudo privileges to
    the sudo user, not group?

    Regards,

    --
    Nicolas George

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tom Dial@21:1/5 to Jeffrey Walton on Fri Feb 21 03:10:01 2025
    The straight, but blunt, answer here, I think, is to read the man pages for sudo and sudoers (i.e., the /etc/suduoers file that does access control for the sudo command. The command is very flexible and can be tuned to allow specified sudoers to use
    elevated privilege only to execute specific commands. But it is not especially friendly.

    Absent a specific reason to allow otherwise non-privileged users to run specific privileged commands it probably is better to remove sudo and simply log on as the root user to do privileged things. Even for the first case, where ordinary users need tuned
    privileged access, it probably is better practice to activate selinux for the purpose, although the documentation is somewhat inaccessible (Red Hat probably is best).

    The TL;DR here is that for maintaining personal workstations and servers it makes more sense to log in as root, do the work as required, then log out. Or there is "sudo -i" to get an interactive root shell and avoid prepending every command with "sudo."

    Regards,
    Tom Dial

    On 2/20/25 15:29, Jeffrey Walton wrote:
    Hi Everyone,

    I have a fresh Debian 12.9 install. My user account is part of sudo
    group, and members of sudo can run any command. However, I get an
    error when trying to use sudo:

    $ sudo ls
    [sudo] password for jwalton:
    jwalton is not in the sudoers file.

    $ groups
    jwalton cdrom floppy sudo audio dip video plugdev users netdev
    bluetooth lpadmin scanner

    $ su -
    Password:

    # grep -v -E '^#' /etc/sudoers | cat -s
    Defaults env_reset
    Defaults mail_badpass
    Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"

    Defaults use_pty

    root ALL=(ALL:ALL) ALL

    sudo ALL=(ALL:ALL) ALL

    I've rebooted the machine twice. I know the failure is not due to
    stale login information.

    Does anyone know why I cannot use sudo in this case?

    Jeff

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Tom Dial on Fri Feb 21 10:20:01 2025
    On Fri Feb 21, 2025 at 1:40 AM GMT, Tom Dial wrote:
    The straight, but blunt, answer here, I think, is to read the man
    pages for sudo and sudoers

    In principle I agree with this advice but the sudoers manpage is
    notoriously, famously inscrutable.


    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    ✎ jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From tomas@tuxteam.de@21:1/5 to Jonathan Dowland on Fri Feb 21 10:30:02 2025
    On Fri, Feb 21, 2025 at 09:12:49AM +0000, Jonathan Dowland wrote:
    On Fri Feb 21, 2025 at 1:40 AM GMT, Tom Dial wrote:
    The straight, but blunt, answer here, I think, is to read the man pages
    for sudo and sudoers

    In principle I agree with this advice but the sudoers manpage is
    notoriously, famously inscrutable.

    Start with the EXAMPLES section. Work from there. It'll come.

    Cheers
    --
    t

    -----BEGIN PGP SIGNATURE-----

    iF0EABECAB0WIQRp53liolZD6iXhAoIFyCz1etHaRgUCZ7hGAgAKCRAFyCz1etHa RuQzAJ9THZeF4QYgx27eeCjkjubl4h7B9QCfaaUiG01CgcyKTcvUvdGB0VlxRW0=
    =Z7sM
    -----END PGP SIGNATURE-----

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Greg on Fri Feb 21 22:20:01 2025
    On Fri Feb 21, 2025 at 2:36 PM GMT, Greg wrote:
    If you had to pick a man page to be inscrutable, this wouldn't be the
    one.

    I mean, for me, it is: don't tell me worse ones. I don't think I want to
    see them…


    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    ✎ jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Tom Dial@21:1/5 to jeremy ardley on Sat Feb 22 00:20:01 2025
    On 2/20/25 22:17, jeremy ardley wrote:
    On 21/2/25 09:40, Tom Dial wrote:
    The TL;DR here is that for maintaining personal workstations and servers it makes more sense to log in as root, do the work as required, then log out. Or there is "sudo -i" to get an interactive root shell and avoid prepending every command with "sudo.
    "


    Logging in as root on a server is highly dangerous, especially if it has an internet facing ssh port. The big cloud providers like AWS provision images where there is no root login, and any access requires a client certificate for a non root user.

    I do not see how login as the root user is meaningfully more dangerous in the case of personal workstations and servers than having a sudoers file that includes "%sudo ALL=(ALL:ALL) ALL."


    The logged in user can sudo. However on some systems like Ubuntu derived, root user doesn't even have a password or a shell. So the first thing I do is

    sudo passwd root

    and work from there.

    With an enabled root password?

    However, certificate based access using e.g. ssh-copy-id is a time-bomb. Best practice is a separate IAM mechanism with centralised access control. I personally use LDAP to maintain ssh public keys backed up by an authenticator on each host. I do not
    permit root accounts in the IAM.

    This seems a bit heavy-duty for personally owned and operated equipment on, e.g., residential premises.

    For whatever it is worth, I use ssh with passworded login prohibited for all network logins. Root login is restricted to a single account on each system and one on a server that runs the backups. On some of the systems the root account does not have a
    password, on on most it does; this depends on the installer defaults and my inclination at installation time. It probably is better practice to not have a root password, but having it makes it marginally easier to handle a possible failure of the ssh
    server.

    Regards,
    Tom Dial

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)
  • From Jonathan Dowland@21:1/5 to Greg on Sun Feb 23 12:20:01 2025
    On Sat Feb 22, 2025 at 2:40 PM GMT, Greg wrote:
    I've never used it myself; here on my single-user machine, I just su
    to root.

    Have you ever looked at the manpage? Specifically the sudoers(5)
    one. There's a preamble "Quick guide to EBNF" to try and summarize
    how to interpret the grammar specifications that follow. This is
    not, in my book, an easy-to-consume manual.

    As another has written, skipping to EXAMPLES helps; that's 85% of
    the way down the page.

    I do understand, however, the usefulness of fine-tuning access to
    privileged functionalities on a computer with multiple users.

    Sure. But that's orthogonal to how suitable the manpage is.


    --
    Please do not CC me for listmail.

    👱🏻 Jonathan Dowland
    ✎ jmtd@debian.org
    🔗 https://jmtd.net

    --- SoupGate-Win32 v1.05
    * Origin: fsxNet Usenet Gateway (21:1/5)