Title. Long,short story: creating or editing files with nano as my non-root user gives (the file) elevated privileges, like I have ran it w/ sudo or as root. And the (only) “security hole” that I can think of is a nextdns docker container running as root. That aside, its very “overkill” security-wise (cap_drop=ALL, non-root image, security_opt=no_new_privileges, etc.).

It’s like someone tried to hack me but gave up halfway. Am I right or wrong to assume this? Just curious.

Thanks in advance.

  • bolapara
    link
    fedilink
    English
    arrow-up
    7
    ·
    1 year ago

    Can you be more specific about what you mean by this: “gives (the file) elevated privileges”?

    • GustavoM@lemmy.worldOP
      link
      fedilink
      English
      arrow-up
      1
      ·
      edit-2
      1 year ago

      i.e file is created (as non-root), trying to remove the file (once again, as non-root) gives me a “rm: cannot remove 'dir/file.name': Permission denied” error message.

      • bolapara
        link
        fedilink
        English
        arrow-up
        6
        ·
        1 year ago

        OK I see. Can you create a new file with nano and then do an “ls -l” so we can see the permissions it’s given? Also provide the output of the command “umask” as the user you’re working with.

        • GustavoM@lemmy.worldOP
          link
          fedilink
          English
          arrow-up
          1
          arrow-down
          1
          ·
          1 year ago

          Just did it, and it shows my sudoer username with ownership of the created file. umask returns me 0002.

          • bolapara
            link
            fedilink
            English
            arrow-up
            7
            ·
            1 year ago

            Can you paste the line from ls -l? Sanitize the username/date/time if you need to. Example:

            -rw-r–r-- 1 bolapara users 0 Nov 21 17:19 asdf

              • Nibodhika@lemmy.world
                link
                fedilink
                arrow-up
                3
                arrow-down
                1
                ·
                1 year ago

                That is not an elevated permission, your user should be able to delete that file, do the same in another directory if it works it might be a permission, or more likely an attribute, problem on the directory itself or something on the path to it.

                • bizdelnick
                  link
                  fedilink
                  arrow-up
                  3
                  ·
                  edit-2
                  1 year ago

                  You cannot say if user able do delete the file or not. It depends on the directory permissions (deleting a file is modifying a directory).

      • gedhrel@lemmy.world
        link
        fedilink
        arrow-up
        5
        ·
        1 year ago

        What are the permissions on the directory? What is command are you running to edit the file? What command are you running to delete it? (Have you got selinux turned on? What filesystem is this directory on?)