6 ms·

>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
    The other reply already covered the definition of hard links. It's a directory entry that points to an inode. And file system corruption is definitely a loophole. > 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. All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. > if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access That's why I said every hard link to the file!
    - inkyoto 4y ago
      > And file system corruption is definitely a loophole. Zero directory entries pointing to an i-node is not a file system corruption as it neither corrupts the file system nor breaks the file system semantics; it is possible to have a garbage collector running in the background to mop up orphaned i-nodes with the file system remaining fully operational at the same time. Distinct i-nodes pointing to the same block allocation, on the other hand, are a security loop hole and create consistency problems. Whether they cause the file system corruption or not is a matter of an academic debate, though. > All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. It is possible to design and write a file system implementation that will retain the UNIX file systems semantics of i-nodes and directory entries whilst remaining completely flat (i.e. no directory hierarchies, just «.»). Such a file sysem would be impractical for most use cases today but is easily possible, and such file systems had been a commonplace before the UNIX file system arrival. Earlier on, you had mentioned: «If there's any loopholes in that, they could be closed». The example below (which is perfectly legit and does not contain semantic loopholes), which of directories does «file.txt» belong in or descends from/ascends into: 1) «a/b/c», 2) «d/e/f/g», 3) «.», 4) all of them? Which of the three directories is more specific and why, and what about future hard links? $ mkdir -p a/b/c $ mkdir -p d/e/f/g $ echo 'I am a file' >file.txt $ chown 0:0 file.txt $ chmod 666 file.txt $ ln file.txt a/b/c $ ln file.txt d/e/f/g $ sudo chown 0:0 a $ sudo chmod 700 a $ ls -l a ls: cannot open directory 'a': Permission denied $ ls -l d/e/f/g/file.txt -rw-rw-rw- 3 root wheel 12 Aug 14 23:59 d/e/f/g/file.txt $ ls -l ./file.txt -rw-rw-rw- 3 root wheel 12 Aug 14 23:59 ./file.txt $ echo 'Anyone can access me' >./file.txt $ cat ./file.txt Anyone can access me

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
  The other reply already covered the definition of hard links. It's a directory entry that points to an inode. And file system corruption is definitely a loophole. > 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. All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. > if a hard link to the same i-node exists in a another unrelated directory outside the current hierarchy that has more permissive access That's why I said every hard link to the file!
  - inkyoto 4y ago
    > And file system corruption is definitely a loophole. Zero directory entries pointing to an i-node is not a file system corruption as it neither corrupts the file system nor breaks the file system semantics; it is possible to have a garbage collector running in the background to mop up orphaned i-nodes with the file system remaining fully operational at the same time. Distinct i-nodes pointing to the same block allocation, on the other hand, are a security loop hole and create consistency problems. Whether they cause the file system corruption or not is a matter of an academic debate, though. > All the filesystems I'm sufficiently aware of insist on directories being a tree. Every entry except the special .. descends in that tree. And each hard link is in a specific directory. It is possible to design and write a file system implementation that will retain the UNIX file systems semantics of i-nodes and directory entries whilst remaining completely flat (i.e. no directory hierarchies, just «.»). Such a file sysem would be impractical for most use cases today but is easily possible, and such file systems had been a commonplace before the UNIX file system arrival. Earlier on, you had mentioned: «If there's any loopholes in that, they could be closed». The example below (which is perfectly legit and does not contain semantic loopholes), which of directories does «file.txt» belong in or descends from/ascends into: 1) «a/b/c», 2) «d/e/f/g», 3) «.», 4) all of them? Which of the three directories is more specific and why, and what about future hard links? $ mkdir -p a/b/c $ mkdir -p d/e/f/g $ echo 'I am a file' >file.txt $ chown 0:0 file.txt $ chmod 666 file.txt $ ln file.txt a/b/c $ ln file.txt d/e/f/g $ sudo chown 0:0 a $ sudo chmod 700 a $ ls -l a ls: cannot open directory 'a': Permission denied $ ls -l d/e/f/g/file.txt -rw-rw-rw- 3 root wheel 12 Aug 14 23:59 d/e/f/g/file.txt $ ls -l ./file.txt -rw-rw-rw- 3 root wheel 12 Aug 14 23:59 ./file.txt $ echo 'Anyone can access me' >./file.txt $ cat ./file.txt Anyone can access me