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.

  • 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.

    • 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?)

    • bolapara@lemmy.ml
      link
      fedilink
      English
      arrow-up
      4
      ·
      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@lemmy.ml
          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@lemmy.ml
                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).