4 ms·

Yup, this is a very common misconception. In Unix, directories are not folders. Directories are literally a directory, like a phone book. It lists files and the

Yup, this is a very common misconception. In Unix, directories are not folders. Directories are literally a directory, like a phone book. It lists files and their location on disk. A directory doesn't contain any other files. Moving a file from one directory to another only modifies the directories, not the file itself. https://unix.stackexchange.com/questions/684122/what-permissions-on-a-file-or-directory-are-needed-to-cp-mv-and-rename-or-make https://unix.stackexchange.com/questions/684122/what-permiss...

Dylan16807 4y ago
So what? Windows likes the word folders but it works the same way. And you could easily have file access permissions depend on the directory if you wanted to.
- dahfizz 4y ago
  > So what? Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. > And you could easily have file access permissions depend on the directory if you wanted to. No, because you can have multiple links in multiple directories all pointing to the same file.
  - Dylan16807 4y ago
    > Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. I don't really see the logic that way. Even if it was "inside", this permission failure would still happen. And directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized. > No, because you can have multiple links in multiple directories all pointing to the same file. Well I put the word "access" there to try to be clearer. If you as system designer wanted to, you could have the path you take to a file affect permissions, even with the 'directory' model and multiple hard links. Heck, you could have permissions be on links instead of on files. YOLO.
    - dahfizz 4y ago
      >And directories, if used properly, can protect a 777 file from being changed. Could you explain how this would work?
      - Dylan16807 4y ago
        Say every hard link to the file is a descendant of a directory that blocks traversal. No subdirectories of those are already open, and the file is not already open. That keeps it safe, right? If there's any loopholes in that, they could be closed.
        inkyoto 4y ago
        > Say every hard link to the file […] Ehr, no. Again, there are no files in the conventional sense in UNIX file systems. There are collections of disk blocks pointed to by an i-node and one or more directory entries pointing to an i-node. It is possible to have an i-node with 0 directory entries linking to it as well as multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node; both are treated as file system errors by fsck and will be fixed up at the next fsck run. Yet, both scenarios can be easily reproduced (without corrupting the file system!) in a file system debugger and live on for a while. > […] a descendant of a directory that blocks traversal. No subdirectories of those […] Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. A directory might be «protected» by, say, 700 permissions obscuring a particular directory entry, but if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access, say 755, access to data blocks referenced to by an i-node has already leaked out.
        mnw21cam 4y ago
        > multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node That's what a hard link is. What we call hard links in Unix/Linux is when you have multiple distinct directory entries referencing the same inode.

Dylan16807 4y ago

So what? Windows likes the word folders but it works the same way. And you could easily have file access permissions depend on the directory if you wanted to.

dahfizz 4y ago
> So what? Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. > And you could easily have file access permissions depend on the directory if you wanted to. No, because you can have multiple links in multiple directories all pointing to the same file.
- Dylan16807 4y ago
  > Using the "folder" mental model leads to exactly the bugs in TFA. "Oh, the root folder can only be accessed by root, so if I put a file _inside_ that folder it will be protected". Thats not how it works. I don't really see the logic that way. Even if it was "inside", this permission failure would still happen. And directories, if used properly, can protect a 777 file from being changed. The error in the mental model is in how permissions work, not how files are organized. > No, because you can have multiple links in multiple directories all pointing to the same file. Well I put the word "access" there to try to be clearer. If you as system designer wanted to, you could have the path you take to a file affect permissions, even with the 'directory' model and multiple hard links. Heck, you could have permissions be on links instead of on files. YOLO.
  - dahfizz 4y ago
    >And directories, if used properly, can protect a 777 file from being changed. Could you explain how this would work?
    - Dylan16807 4y ago
      Say every hard link to the file is a descendant of a directory that blocks traversal. No subdirectories of those are already open, and the file is not already open. That keeps it safe, right? If there's any loopholes in that, they could be closed.
      - inkyoto 4y ago
        > Say every hard link to the file […] Ehr, no. Again, there are no files in the conventional sense in UNIX file systems. There are collections of disk blocks pointed to by an i-node and one or more directory entries pointing to an i-node. It is possible to have an i-node with 0 directory entries linking to it as well as multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node; both are treated as file system errors by fsck and will be fixed up at the next fsck run. Yet, both scenarios can be easily reproduced (without corrupting the file system!) in a file system debugger and live on for a while. > […] a descendant of a directory that blocks traversal. No subdirectories of those […] Directory entries in a UNIX file system do not ascend nor descend, they are linked into one or more directories whether they form a hierarchy or not. A directory might be «protected» by, say, 700 permissions obscuring a particular directory entry, but if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access, say 755, access to data blocks referenced to by an i-node has already leaked out.
        mnw21cam 4y ago
        > multiple unrelated (i.e. not hard links but truly disjoint directory entries) directory entries referencing the same i-node That's what a hard link is. What we call hard links in Unix/Linux is when you have multiple distinct directory entries referencing the same inode.