4 ms·

> 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

> 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

Dylan16807 4y ago
> 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. Yeah, it would also be possible to design a system that doesn't enforce permissions. The challenge here is whether you can make a reasonable design that's secure. Not whether any design would be secure; that's self-obviously false. Anyone doing the designing can choose not to use a special bespoke filesystem. But I don't see how your described filesystem would cause problems. The directory entries are still descendants of the directories they are in. Apply the rest of the logic and those files are secure. It's easier, really, when you don't have to worry about subdirectories. If subdirectories don't exist, they can't be open. > 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? The file is not in a specific directory. Links to the file are in `pwd`, a/b/c, and d/e/f/g. "Being in" is the same as "descending from". If you secure `pwd` (and nothing is already open), then all three hard links will be secured. Or if you remove the hard link in `pwd`, and secure g (and nothing is already open), then the file will be secured. "./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"? If future hard links are made, then they follow the same rules. If any hard link is not secured, then the file is not secured. And a user without access to the file cannot make a new hard link to the file.
- inkyoto 4y ago
  > Yeah, it would also be possible to design a system that doesn't enforce permissions. It is even easier than that: one only has to simply detach the disk and reattach it to another UNIX box to gain access to any file as the file system itself is defenceless and offers no protection from the physical access to its on-disk layout. File system encryption is the only solution that makes physical impractical or at least convoluted. And, since UNIX file systems delegate permissons checks to the kernel via the VFS, it is also possible for a person with nefarious intentions to modify the file system code to make it always return 777 for any i-node being accessed through it, find a local zero day exploit, load the rogue file system kernel module and remount file system(s) to bypass the permission enforcement in the kernel. The reverse is also true: if the kernel and the file system support access control lists, standard UNIX file permissions become largely meaningless, and it becomes possible to grant or revoke access to/from a file owned by root with 600 permissions to an arbitrary user/group only. Using the same example from above: $ cat ./file.txt Anyone can access me $ sudo /bin/chmod +a "group:staff deny write" ./file.txt $ /bin/ls -le ./file.txt -rw-rw-rw-+ 3 root wheel 21 14 Aug 23:59 ./file.txt 0: group:staff deny write $ echo 'No-one from the staff group can access me any longer' >./file.txt zsh: permission denied: ./file.txt $ id uid=NNNNNN(morally.bold.mollusk) gid=MMMMMM(staff) groups=MMMMMM(staff),[… redacted …] $ ls -la ./file.txt -rw-rw-rw-+ 3 root wheel 21 Aug 15 17:28 ./file.txt > The challenge here is whether you can make a reasonable design that's secure. Indeed, rarely can security be bolted on with any measurable success, and a system can be secure only if it is secure by design. But security is also a game of the constant juggling of trade-offs that may or may not be acceptable in a particular use case. Highly secure designs are [nearly always] hostile to users and are a tremendous nuisance in the daily use. The UNIX answer to security is delegation of responsibilities: «I, UNIX, will do a reasonable job on keeping the system secure, but the onus is on you, user, to excercise the due diligence, and – oh, by the way – here is a shotgun to shoot yourself in the foot (and injure bystanders as a bonus) if you, the user, are negligent about keeping your data secure». > "./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"? The point I was trying to make was that specificness is a purely logical concept. In the aforementioned example, there are 3x directory entries at 3x arbitrary locations and any of them can be used to access the data referenced to via an i-node. Once a file is opened using either of those three directory entries, it is not possible to trace the open file descriptor back to a specific directory entry. Therefore, none of the three directory entries is more specific than the others – they are all equal.

Dylan16807 4y ago

> 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. Yeah, it would also be possible to design a system that doesn't enforce permissions. The challenge here is whether you can make a reasonable design that's secure. Not whether any design would be secure; that's self-obviously false. Anyone doing the designing can choose not to use a special bespoke filesystem. But I don't see how your described filesystem would cause problems. The directory entries are still descendants of the directories they are in. Apply the rest of the logic and those files are secure. It's easier, really, when you don't have to worry about subdirectories. If subdirectories don't exist, they can't be open. > 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? The file is not in a specific directory. Links to the file are in `pwd`, a/b/c, and d/e/f/g. "Being in" is the same as "descending from". If you secure `pwd` (and nothing is already open), then all three hard links will be secured. Or if you remove the hard link in `pwd`, and secure g (and nothing is already open), then the file will be secured. "./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"? If future hard links are made, then they follow the same rules. If any hard link is not secured, then the file is not secured. And a user without access to the file cannot make a new hard link to the file.

inkyoto 4y ago
> Yeah, it would also be possible to design a system that doesn't enforce permissions. It is even easier than that: one only has to simply detach the disk and reattach it to another UNIX box to gain access to any file as the file system itself is defenceless and offers no protection from the physical access to its on-disk layout. File system encryption is the only solution that makes physical impractical or at least convoluted. And, since UNIX file systems delegate permissons checks to the kernel via the VFS, it is also possible for a person with nefarious intentions to modify the file system code to make it always return 777 for any i-node being accessed through it, find a local zero day exploit, load the rogue file system kernel module and remount file system(s) to bypass the permission enforcement in the kernel. The reverse is also true: if the kernel and the file system support access control lists, standard UNIX file permissions become largely meaningless, and it becomes possible to grant or revoke access to/from a file owned by root with 600 permissions to an arbitrary user/group only. Using the same example from above: $ cat ./file.txt Anyone can access me $ sudo /bin/chmod +a "group:staff deny write" ./file.txt $ /bin/ls -le ./file.txt -rw-rw-rw-+ 3 root wheel 21 14 Aug 23:59 ./file.txt 0: group:staff deny write $ echo 'No-one from the staff group can access me any longer' >./file.txt zsh: permission denied: ./file.txt $ id uid=NNNNNN(morally.bold.mollusk) gid=MMMMMM(staff) groups=MMMMMM(staff),[… redacted …] $ ls -la ./file.txt -rw-rw-rw-+ 3 root wheel 21 Aug 15 17:28 ./file.txt > The challenge here is whether you can make a reasonable design that's secure. Indeed, rarely can security be bolted on with any measurable success, and a system can be secure only if it is secure by design. But security is also a game of the constant juggling of trade-offs that may or may not be acceptable in a particular use case. Highly secure designs are [nearly always] hostile to users and are a tremendous nuisance in the daily use. The UNIX answer to security is delegation of responsibilities: «I, UNIX, will do a reasonable job on keeping the system secure, but the onus is on you, user, to excercise the due diligence, and – oh, by the way – here is a shotgun to shoot yourself in the foot (and injure bystanders as a bonus) if you, the user, are negligent about keeping your data secure». > "./a" descends from ".", one hard link to the file descends from ".", "./a/b" descends from "./a", "./a/b/c" descends from "./a/b", one hard link to the file descends from "./a/b/c". Plus the same for d/e/f/g, plus every transitive descent like "./a/b" descending from "." I hope that's what you mean by "more specific"? The point I was trying to make was that specificness is a purely logical concept. In the aforementioned example, there are 3x directory entries at 3x arbitrary locations and any of them can be used to access the data referenced to via an i-node. Once a file is opened using either of those three directory entries, it is not possible to trace the open file descriptor back to a specific directory entry. Therefore, none of the three directory entries is more specific than the others – they are all equal.