ber@enea.UUCP (Bjorn Eriksen) (01/06/85)
It turned out that I didn't create an infinit number of subdirectories
but rather a directory linked to itself, that is in directory A I have
directory B which is a symbolic link to A. As soon as I create a file
in A it will appear in B and B/B and B/B/B ... The odd thing is that B
isn't marked as a symbolic link but as an ordinary directory.
How do I get rid of it?
--
Bjorn Eriksen
ENEA DATA Sweden
UUCP: {decvax,philabs}!mcvax!enea!ber
ARPA: decvax!mcvax!enea!ber@berkeley.arpa
mcvax!enea!ber@seismo.arpajohn@mplvax.UUCP (John McInerney) (01/07/85)
In article <792@enea.UUCP> ber@enea.UUCP (Bjorn Eriksen) writes: >I just used 'patch' on a diff but didn't notice that the diff referred >to subdirectories that I didn't have. Patch creates a subdirectory .orig >and somehow it started to create them recursivly, .orig/.orig/.orig/..., >until I guess a "filname too long" error. The problem is now how do I >get rid of .orig without redo the filesystem? A "rm -rf .orig" fails. >This is 4.2BSD. > >-- > Bjorn Eriksen > ENEA DATA Sweden > > UUCP: {decvax,philabs}!mcvax!enea!ber > ARPA: decvax!mcvax!enea!ber@berkeley.arpa > mcvax!enea!ber@seismo.arpa What I did to get rid of these .orig files was to move the parent directory of the offending .orig calling it "blackhole" and then used tar to move the hierarchy to its correct place (not including the .orig file of course) with commands something like: mkdir gooddir cd blackhole tar cpf - [a-z]* | (cd ../gooddir; tar xpf - ) Then I used the following C program to get rid of the .orig directory. ----------------------------------------------------------------------------- main(){ if (unlink("blackhole/.orig")){ perror("rmblck:"); } } ----------------------------------------------------------------------------- I think that you could directly use the unlink(2) call to remove just the .orig directory, but I was paranoid that I would remove the good stuff too. Also, I believe that there are two occurances of the .orig link to parent in the 4.2 distribution. A find started from root should find them for you; be sure to redirect the error output. John McInerney sdcsvax!mplvax!john UUCP john@nosc ARPA
avolio@grendel.UUCP (Frederick M. Avolio) (01/07/85)
> It turned out that I didn't create an infinit number of subdirectories > but rather a directory linked to itself, that is in directory A I have > directory B which is a symbolic link to A. As soon as I create a file > in A it will appear in B and B/B and B/B/B ... There's a sign-post up ahead... Bjorn Erikson has entered....The Twilight Zone! -- Fred Avolio 301/731-4100 x4227 UUCP: {seismo,decvax}!grendel!avolio ARPA: grendel!avolio@seismo.ARPA
henry@utzoo.UUCP (Henry Spencer) (01/08/85)
> It turned out that I didn't create an infinit number of subdirectories > but rather a directory linked to itself, that is in directory A I have > directory B which is a symbolic link to A. As soon as I create a file > in A it will appear in B and B/B and B/B/B ... Aren't symbolic links delightful? -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
ber@enea.UUCP (Bjorn Eriksen) (01/11/85)
I just used 'patch' on a diff but didn't notice that the diff referred
to subdirectories that I didn't have. Patch creates a subdirectory .orig
and somehow it started to create them recursivly, .orig/.orig/.orig/...,
until I guess a "filname too long" error. The problem is now how do I
get rid of .orig without redo the filesystem? A "rm -rf .orig" fails.
This is 4.2BSD.
--
Bjorn Eriksen
ENEA DATA Sweden
UUCP: {decvax,philabs}!mcvax!enea!ber
ARPA: decvax!mcvax!enea!ber@berkeley.arpa
mcvax!enea!ber@seismo.arpathomas@utah-gr.UUCP (Spencer W. Thomas) (01/12/85)
In article <4883@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >> It turned out that I didn't create an infinit number of subdirectories >> but rather a directory linked to itself, that is in directory A I have >> directory B which is a symbolic link to A. As soon as I create a file >> in A it will appear in B and B/B and B/B/B ... > >Aren't symbolic links delightful? I doubt very much it was a symbolic link - he said it showed up in the 'ls' listing as a real directory. Also, you can easily remove a symbolic link. I think it was a real link (only possible under 4.2 when running as root, and VERY dangerous). Oh - yes, symbolic links are delightful (and not in the sense you meant it, either). =S -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) <<< Silly quote of the week >>>
ellis@spar.UUCP (Michael Ellis) (01/15/85)
From Spencer Thomas: >In article <4883@utzoo.UUCP> henry@utzoo.UUCP (Henry Spencer) writes: >>> It turned out that I didn't create an infinit number of subdirectories >>> but rather a directory linked to itself, that is in directory A I have >>> directory B which is a symbolic link to A. As soon as I create a file >>> in A it will appear in B and B/B and B/B/B ... >> >>Aren't symbolic links delightful? > >I doubt very much it was a symbolic link - he said it showed up in the >'ls' listing as a real directory. Also, you can easily remove a >symbolic link. I think it was a real link (only possible under 4.2 when >running as root, and VERY dangerous). I also accidentally created a HARD link, using patch, that behaved as Henry Spencer's monster. And it wrought havoc with our nightly filesystem maintenance -- guess how long a `find' on the partition containing such a directory will run... Getting rid of the black hole was NOT fun. Assuming Henry's experience was related to mine, I wonder how could patch do such an evil thing? And how can I avoid this in the future, short of removing `patch'? And just how is it possible for `root' to create such a directory in 4.2 without writing to raw disc? -michael
rpw3@redwood.UUCP (Rob Warnock) (01/16/85)
+--------------- | I also accidentally created a HARD link, using patch,... | ... I wonder how could patch do such an evil thing? | And just how is it possible for `root' to create such a directory in 4.2 | without writing to raw disc? | -michael +--------------- WARNING!!! It has ALWAYS been possible (on any UNIX I know) for a superuser to create a (hard) link to a directory. While the "ln" program (command) will not allow it, the system call does (for the superuser) and must (for "mv"). Any program that runs as root and does not use 'system("/bin/ln ...")' for making links (or 'system("mv ...")' for renaming) should have defensive code. (It's actually useful, on occasion, to make a hard link to a directory, to temporarily work around problems with hard-coded paths in binary programs. This is not particularly a problem if you don't create a loop.) Rob Warnock Systems Architecture Consultant UUCP: {ihnp4,ucbvax!dual}!fortune!redwood!rpw3 DDD: (415)572-2607 USPS: 510 Trinidad Lane, Foster City, CA 94404
Ron Natalie <ron@BRL-TGR> (01/17/85)
> And just how is it possible for `root' to create such a directory in 4.2 > without writing to raw disc? just say link("dir", "new name"); in a program. The restriction about linking directories is built into the link program.
chris@umcp-cs.UUCP (Chris Torek) (01/18/85)
> The restriction about linking directories is built into > the link program. Not in 4.2BSD it's not! I think it was in the 4.1 kernel as well. (I haven't seen any other kernel sources, so I wouldn't know about V6/V7/Sn.) -- (This line accidently left nonblank.) In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 7690) UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland
Ron Natalie <ron@BRL-TGR> (01/18/85)
>> The restriction about linking directories is built into >> the link program. >Not in 4.2BSD it's not! I think it was in the 4.1 kernel as well. >(I haven't seen any other kernel sources, so I wouldn't know about >V6/V7/Sn.) It is too! I just linked up a directory like that with the following program... main(argc, argv) int argc; char **argv; { if(argc != 3) { printf("arg count\n"); exit(1); } if(link(argv[1], argv[2]) == -1) { perror("link"); } } I just looked at the code and it checks for IFMT == IF_DIR and !suser()!
guy@rlgvax.UUCP (Guy Harris) (01/18/85)
> > The restriction about linking directories is built into > > the link program. > > Not in 4.2BSD it's not! I think it was in the 4.1 kernel as well. > (I haven't seen any other kernel sources, so I wouldn't know about > V6/V7/Sn.) All UNIX systems since V6 (and probably some before, although I think some VERY early versions - like the assembly-language ones) have only allowed the super-user to make links to directories. On the other hand, the original poster asked how "root" could create a directory which referenced itself without writing directly to the file system; since it was "root", there were no restrictions on the "link" call for them. Guy Harris {seismo,ihnp4,allegra}!rlgvax!guy
bsa@ncoast.UUCP (Brandon Allbery (the tame hacker on the North Coast)) (01/24/85)
> Article <2547@umcp-cs.UUCP>, from chris@umcp-cs.UUCP (Chris Torek) +---------------- | > The restriction about linking directories is built into | > the link program. | | Not in 4.2BSD it's not! I think it was in the 4.1 kernel as well. | (I haven't seen any other kernel sources, so I wouldn't know about | V6/V7/Sn.) V7 allows it; it's how /bin/mkdir works. In fact, I just had to write a custom mkdir because /bin/mkdir was using the wrong uid to compute access permissions. I can see why 4.2's mkdir system call would be useful. Also: Plexus P/35 (System III) has /etc/link which links directories and is billed to be /bin/ln without error checking (for root only). --bsa -- Brandon Allbery @ decvax!cwruecmp!ncoast!bsa (..ncoast!tdi1!bsa business) 6504 Chestnut Road, Independence, Ohio 44131 +1 216 524 1416 (or what have you) Who said you had to be (a) a poor programmer or (b) a security hazard to be a hacker?