• xia@lemmy.sdf.orgEnglish
    0·
    22 days ago

    Getting flashbacks of me trying to explain to a mac user why using sudo “to make it work” is why he had a growing problem of needing to use sudo… (more and more files owned by root in his home folder).

    • InnerScientist@lemmy.world
      0·
      22 days ago

      Sounds like a problem fixing itself, at some point MacOS is going to have problems if it can’t edit a config is my guess.

  • Sixty@sh.itjust.worksEnglish
    0·
    22 days ago

    sudo dolphin

    Then I act like a Windows user and go there via the GUI because I didn’t feel like learning how to use nano.

    • bishbosh@lemm.eeEnglish
      0·
      22 days ago

      If you’re running dolphin as sudo and open like a text file in an editor, does it edit the file with sudo?

      • tal@lemmy.todayEnglish
        0·
        22 days ago

        When you run a process under sudo, it will be running as the root user. Processes that that process launches will also be running as the root user; new processes run as the same user as their parent process.

        So internally, no, it won’t result in another invocation of sudo. But those processes a dolphin process running as root starts will be running as the root user, same as if you had individually invoked them via sudo.

  • aesthelete@lemmy.world
    0·
    22 days ago

    This is definitely the way for configuration files that you shouldn’t change permissions or ownership on but only want to modify a few times.

    However, I find chmod easier to use without reference by using the ugoa (+/-) rwxXst syntax rather than the numbers.

  • SleepyPie@lemmy.world
    0·
    22 days ago

    If it’s all my system should I really care about chown and chmod? Is the point that automatic processes with user names like www-data have to make edits, and need permission to do so, and that’s it?

    Newish Linux user btw

    • corsicanguppy@lemmy.caEnglish
      0·
      22 days ago

      Short answer: yes.

      One of the tenets of security is that a user or process should have only enough access to do what it needs, and then no more. So your web server, your user account, to your mail server, should have exactly what they need, and usually that’s been intricately planned by the distro.

      If you subvert it you could be writing files as root that www-data now can’t read or write. This kind of error is sometimes obvious and sometimes very subtle.

      Especially if you’re new to this different access model, tread carefully.

      Great news! If you need it up, many distros are really great at allowing you cm to compare permissions and reset them. The bad news is that maybe you’re not on one of those. But you could be okay.

    • palordrolap@fedia.io
      0·
      22 days ago

      In addition to corsicanguppy’s comment, some — often important — programs actually expect the system to be secured in a particular way and will refuse to function if things don’t look right.

      Now, you’d be right to expect that closing down permissions too tightly could break a system, but people have actually broken their systems by setting permissions too openly on the wrong things as well.

      That said, for general, everyday use, those commands don’t need to be used much, and there might even be a way to do what they do from your chosen GUI. Even so, it nice to know they’re there and what they do for those rare occasions when they might be needed.

    • Albbi@lemmy.ca
      0·
      22 days ago

      Why memorize a different command? I assume sudoedit just looks up the system’s EDITOR environment variable and uses that. Is there any other benefit?

      • Arthur Besse@lemmy.mlEnglish
        0·
        22 days ago

        Why memorize a different command? I assume sudoedit just looks up the system’s EDITOR environment variable and uses that. Is there any other benefit?

        I don’t use it, but, sudoedit is a little more complicated than that.

        details

        from man sudo:

        When invoked as sudoedit, the -e option (described below), is implied.

               -e, --edit
               Edit one or more files instead of running a command.   In  lieu
               of  a  path name, the string "sudoedit" is used when consulting
               the security policy.  If the user is authorized by the  policy,
               the following steps are taken:

               1.   Temporary  copies  are made of the files to be edited with
                    the owner set to the invoking user.

               2.   The editor specified by the policy is run to edit the tem‐
                    porary files.  The sudoers policy  uses  the  SUDO_EDITOR,
                    VISUAL  and  EDITOR environment variables (in that order).
                    If none of SUDO_EDITOR, VISUAL  or  EDITOR  are  set,  the
                    first  program  listed  in the editor sudoers(5) option is
                    used.

               3.   If they have been modified, the temporary files are copied
                    back to their original location and the temporary versions
                    are removed.

               To help prevent the editing of unauthorized files, the  follow‐
               ing  restrictions are enforced unless explicitly allowed by the
               security policy:

                •  Symbolic links  may  not  be  edited  (version  1.8.15  and
                   higher).

                •  Symbolic links along the path to be edited are not followed
                   when  the parent directory is writable by the invoking user
                   unless that user is root (version 1.8.16 and higher).

                •  Files located in a directory that is writable by the invok‐
                   ing user may not be edited unless that user is  root  (ver‐
                   sion 1.8.16 and higher).

               Users are never allowed to edit device special files.

               If  the specified file does not exist, it will be created.  Un‐
               like most commands run by sudo, the editor is run with the  in‐
               voking  user's  environment  unmodified.  If the temporary file
               becomes empty after editing, the user will be  prompted  before
               it is installed.  If, for some reason, sudo is unable to update
               a file with its edited version, the user will receive a warning
               and the edited copy will remain in a temporary file.

        tldr: it makes a copy of the file-to-be-edited in a temp directory, owned by you, and then runs your $EDITOR as your normal user (so, with your normal editor config)

        note that sudo also includes a similar command which is specifically for editing /etc/sudoers, called visudo 🤪

        • Flyswat@lemmy.dbzer0.com
          0·
          22 days ago

          visudo is a life-saver since it adds some checks to prevent you from breaking your sudo configuration and locking you out of your system.

      • moonlight@fedia.io
        0·
        22 days ago

        It doesn’t edit the file directly, it creates a temp file that replaces the file when saving. It means that the editor is run as the user, not as root.

        • Albbi@lemmy.ca
          0·
          22 days ago

          So it opens the file in your editor, since you have read access to it. Then saves your changes to a temp file. Then when you close the editor it does a sudo mv tmpfile readfile?

          I checked this by checking the file ownership when running touch myself. The file is owned by root. sudo nano myself also creates a file owned by root. sudoedit myself bitches at me not to run it in a writable directory.

          sudoedit: myself: editing files in a writable directory is not permitted

          So I ran it in a non-writable directory and the resulting file is still owned by root.

          So is the advantage of sudoedit preventing a possible escalation of privileges situation?

          • Russ@bitforged.spaceEnglish
            0·
            22 days ago

            For me personally the advantage is that since the editor is opened by your user, it has all of the same config that I’m used to (such as my souped up Neovim config).

            Whereas if you sudo nvim /path/to/file then the editor is opened as root and you don’t have the same configuration.

            • gi1242@lemmy.world
              0·
              22 days ago

              I just make /root/.config/nvim a symlink to ~/.config/nvim and running nvim as root gives me all the same settings I’m used to. (I’d rather not run nvim-qt as root though, so in that case sudoedit is useful.)

      • sanderium@lemmy.zipEnglish
        0·
        22 days ago

        Correct but it uses the SUDO_EDITOR environment variable. The benefit is more security while editing system files, it creates a temporary file and when you finish it writes changes to the original. There is more to it but that is all I know, it prevents some exploits.

      • morbidcactus@lemmy.ca
        0·
        22 days ago

        From the arch wiki

        sudo -e {file}

        Set SUDO_EDITOR in your profile to the editor of your choice, benefit is it retains your user profile for that editor, it’s also less to type. For stuff like editing sudoers you’re supposed to use visudo to edit that. Others can probably give better/more thorough reasons to consider it.

    • hddsx@lemmy.ca
      0·
      22 days ago

      You won’t be able to do certain things. Either .ssh or ~ expects certain exact permissions and pukes if it’s different, IIRC

      • Cethin@lemmy.zipEnglish
        0·
        22 days ago

        Yep. I fucked up once when I meant to type chmod for something but with “./” but I missed the “.”. It was not good.

      • TipRing@lemmy.worldEnglish
        0·
        21 days ago

        At one of my prior positions they outsourced all the junior engineers to this firm that only had windows desktop support experience.

        Actual escalation I got:

        contractor: I am trying to remove this file that is filling the drive but it won’t let me

        me: show me what you are doing.

        contractor (screenshot): # rm -f /dev/hdc

        another one did rm -rf /var to clear a stuck log file, which at least did solve the problem he was having.

        After that I sent out an email stating that I would not help anyone who used he rm command unless they consulted with a senior first. I was later reprimanded for saying I wouldn’t help people.

        • B-TR3E@feddit.org
          0·
          21 days ago

          I was later reprimanded for saying I wouldn’t help people.

          I’ve heard that before. “No. I won’t close the circuit breaker while you’re holding the wires.” “Boss!..”

      • bitchkat@lemmy.worldEnglish
        0·
        22 days ago

        Back in the olden days we used to nfs mount every other machines file system on every machine. I was root and ran “rm -rf /" instead of "./”.

        After I realized that it was taking too long, i realized my error.

        Now for the fun part. In those days nfs passed root privileges to the remote file system. I took out 2.5 machines before I killed it.

        • baines@lemmy.cafeEnglish
          0·
          22 days ago

          I did this in a cleanup script in a make file with an undefined path that turned the pointed dir to root after a hardware change

          thank rngesus I was in a user account with limited privileges

        • B-TR3E@feddit.org
          0·
          21 days ago

          Back in the olden days we used to nfs mount every other machines file system on every machine. I was root and ran “rm -rf /” instead of “./”.

          I still do. With NFS4 even more than ever. Won’t let it go unless for a SAN.

          Now for the fun part. In those days nfs passed root privileges to the remote file system.

          no_root_squash

          much?

            • B-TR3E@feddit.org
              0·
              21 days ago

              Holy smokes. That must have been before 1989 (that’s when RFC1094 was released, explicitely prohibiting to map the root user to UID 0). I thought, I was old…