On Sun, Sep 14, 2014 at 11:45 PM, Brandon Allbery <[email protected]> wrote:
> On Sun, Sep 14, 2014 at 5:36 PM, Bill Bogstad <[email protected]> wrote: > >> /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. > > > It *did* have a general use, though: ln was, even then, a bit too "user > friendly" to make hardlink-style lock files safely. > I think you are thinking of /bin/ln which was how normal users were supposed to make links to files (with /bin/rm being the way to remove them). I always interpreted anything in /etc as not for general use. In the case of link/unlink, I don't think they did anything that ln/rm couldn't (unless you were root). (I got familiar with link/unlink because of a buggy kernel building script, > provided by the OS vendor, that if invoked in a certain "obvious" way would > ultimately run "ld -o .. config.o ...". "oops") > I'm guessing you were running your kernel builds as root because otherwise ld should not have been able to do anything to the "." entry. Interesting example of a "crack" in the API though. I would also guess that "ld" first wrote to a temporary file and then did unlink/link calls to the final output file as well. I think that even as root an attempt to open a directory ("." or anything else) for direct writing should have failed. Ofcourse once the problem happened then you certainly did need an unrestricted link/unlink to fix it. Bill Bogstad > > -- > brandon s allbery kf8nh sine nomine > associates > [email protected] > [email protected] > unix, openafs, kerberos, infrastructure, xmonad > http://sinenomine.net >
_______________________________________________ Tech mailing list [email protected] https://lists.lopsa.org/cgi-bin/mailman/listinfo/tech This list provided by the League of Professional System Administrators http://lopsa.org/
