Control: tag -1 + confirmed upstream Control: found -1 1.7.0+dfsg-1 [Replying to an old bugreport...]
30.07.2011 16:24, Johannes Schauer wrote: > Package: qemu-user > Version: 0.14.1+dfsg-3 > Severity: normal > > Hi, > > when a symbolic or hardlink which creates a recursive cycle exists in > the directory specified as the elf interpreter prefix > (default=/etc/qemu-binfmt/<arch>/), qemu-user will recursively traverse > this path and never finish (eating tons of memory in the process). > > The easiest way to reproduce is to do: > > ln -s '.' /etc/qemu-binfmt/<arch>/foobar > > (or wherever directory you pointed qemu to with the -L option) > > This is mostly annoying because there exists the /usr/bin/X11 symlink > which points to '.' in debian systems with x11-common installed. Current behavour (as per 1.7) is a bit different - it tries to open /etc/qemu-binfmt/<arch>/foo/foo/foo/foo/..../foo until an error is reported (which is ELOOP (Too many levels of symbolic links)), after which it just stops processing other dirs. When, however, there are 2 or more looping links, it pauses for way too long trying all possible combinations until ELOOP is returned, which is just too many. So things hasn't really changed much. Just refreshing old bugs.... Thanks, /mjt > Other problems occur with /proc/self/fd/ (and /dev/fd/ which links to > it) when /proc is mounted in the elf interpreter prefix path. > > The problem occurs when init_paths() is called on interp_prefix (the elf > interpreter prefix path). init_paths() doesnt protect from infinitely > traversing cyclic symlinks. > > find(1) solves this problem by maintaining a hashtable of (to be) > traversed directories and skipping directories that are found to be > already part of it. > > I can prepare a patch for path.c (which defines init_paths()) which > guards against this behaviour in the same way that find(1) does if this > problem is desired to be solved that way. > > cheers, josch > > > > -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected]
