On Sun, Sep 14, 2014 at 5:09 PM, Brandon Allbery <allber...@gmail.com> wrote:
> On Sun, Sep 14, 2014 at 11:02 AM, Edward Ned Harvey (lopser) < > lop...@nedharvey.com> wrote: > >> > From: Edward Ned Harvey (lopser) >> So the only point in question is whether or not "." and ".." are >> permitted filenames in extfs. I think we all know the answer to this >> question. They are reserved, so if we want to get semantic, we could say >> they are technically permitted, but disallowed for any purposes in user >> space other than read. > > > If you can find an OS API that supports it, there's nothing preventing > their use. For that matter, I once worked with a System III that would > happily allow root to replace . and .. (this predated mkdir/rmdir Unix > APIs) and, while fsck would complain, it "worked". You could create (and, > thankfully, repair) such things as root with /etc/link and /etc/unlink. > Unix has always let users (particularily root) shoot themselves in the foot, so the fact that root could do things to corrupt the filesystem isn't that surprising. A real "hacker" could edit the disk directly via /dev/??? to accomplish the same thing. /etc/*link was just a slightly safer way to accomplish this and in my opinion was intended to fix filesystem corruption not as a supported interface for general use. The mkdir program was setuid root (with appropriate checks) so it could invoke the low-level calls to create a directory via mknod(2) and link(2) system calls. Rmdir was done similarly. Direct manipulation of directories via link/unlink never seemed to me to be a supported interface, but simply a way to implement supported interfaces. Bill Bogstad
_______________________________________________ Tech mailing list Tech@lists.lopsa.org https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
