On Thursday 14 August 2014 05:26:36 Andrew Deason wrote:
> On Wed, 13 Aug 2014 17:45:17 +0200
> Markus Köberl <markus.koeb...@tugraz.at> wrote:
>
> > What about an option to change the behavior of 3. to:
> >
> > 3. If no server list was found in CellServDB and afsdb lookups are
> > enabled, use DNS SRV/AFSDB records to try to find a match only if
> > the search term includes at least one ".". Use DNS SRV/AFSDB queries
> > but deny the resolver the usage of the domain search lists.
>
> This generally sounds reasonable to me. But I think you want to just
> require a dot if the name doesn't exist in the csdb at all, so you can
> just put it in the local csdb if you want to use it, without needing to
> alias it to a full cell name. (This may have been mentioned earlier, but
> I don't see it here.) I'd call such an option -afsdb-ndots, which would
> set the minimum number of dots (like resolv.conf's "option ndots").
This would require changing the format of the CellServDB or did I get something
wrong?
> However, this doesn't solve the issue when files like libX11.so or
> beamer.cls like in your captured list. You really need a blacklist for
> these, or we can just try to improve the negative caching. iirc, we
> already have some hard-coded 'blacklist' entries to appease things like
> OS X's Finder, so a configurable blacklist doesn't seem like such a big
> change. Doing any actual pattern matching could be done in userspace and
> can be very slow if we just cache results in the kernel (keep a
> 'negative' cell struct around).
For normal working I think it would be enough if we try to limit the queries
for SRV records.
One way would be to ignore the domain search lists and another to require a dot
in the query.
Providing a way to manage the blacklist which is already available would be
very useful especially if we have a "fs setblacklist" command in addition to a
config file. I would add the following entries for my cell:
directory
dropbox
git
hg
svn
Trash
Trash-1000
> Some of the entries in your earlier captured list I'm a little
> confused/concerned by, though:
>
> On Wed, 06 Aug 2014 21:46:42 +0200
> Markus Köberl <markus.koeb...@tugraz.at> wrote:
>
> > libX11.so
> > libX11.so.6
> > libX11.so.6.la
> > libX11.so.6.so
> > libX11.so.la
> > libX11.so.so
>
> You really have something that tries to load libraries from the current
> directory (or some ancestor directory)? What if you're in /tmp, or some
> other world-writeable dir? Someone could put a libX11.so in there and
> run arbitrary code as you.
Unbelievable but yes: It is the Midnight Commander (mc)
The list you quoted is from the mc from debian testing.
> > *.ltx
>
> Are these literal '*' characters, by the way? (That is, it's a failed
> glob, not a just a bunch of different entries that end with '.ltx')
Yes it is a failed glob produced by kile.
$ strace -e trace=stat kile 2>&1 | grep 'stat("\*'
stat("*.tex", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.ltx", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.latex", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.dtx", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.ins", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.cls", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.sty", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.bbx", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.cbx", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.lbx", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.bib", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
stat("*.mp", 0x7fff694b05f0) = -1 ENOENT (No such file or directory)
> With some of these entries, even a blacklist will not solve everything.
> It's not possible to know with certainty that libx11.so or matlab7rc.sh
> are not valid cell names without querying dns first; they could be in
> the future. Maybe more-obviously ambiguous examples would be
> 'liberty.so', a real library, or 'brew.sh', a real domain.
Yes but this should not be a problem as long people do not change to /afs and
then start the application.
It should be possible to teach them not to do this...
> A blacklist might help for a vast majority of cases, though. Or of
> course we could just improve the caching, so only the first lookup is
> slow... would that be good enough, if done "well"?
A improved caching would be very nice for the bash completion.
regards
Markus
--
Markus Koeberl
Graz University of Technology
Signal Processing and Speech Communication Laboratory
E-mail: markus.koeb...@tugraz.at
