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