Anselm Martin Hoffmeister <an...@ho...> writes:
> Hello ron,
>
> >> >The case I am making is that normally you don't export your root
> >> >file system from the server. Just like tftp where normally all that
> >> >is exported is /tftpboot. With nfs usually it is some subset of
> >> >the filesystem that is exported. Which is why I think handling absolute
> >> >paths in a way that gives a reasonable error message is much
> >> >preferable.
>
> > symlinks are a big problem no matter what you do. I can make a symlink to
> > another file system easily:
>
> > ../../../../../../../somewhere_else/file
>
> > It can be the same as
> > /somewhere_file/file
>
> > This is a perfectly valid relative link that can go somewhere else.
>
> > I guess I don't see the problem with absolute links that relative links
> > really solves. Either way, if you talk to a server, and it can't resolve
> > the link, you'll get an error.
>
> > And let us not forget things like:
> foo ->> foo
>
> > A perfectly useless symlink, but relative and hence acceptable.
>
> > I'm not convinced that ruling out abs symlinks is really going to help you
> > much.
My only thinking is that with relative links there was some extra
context that would help. But if it is only a little bit of code to
handle absolute as well as relative links I remove all objections.
> One more question is user friendly intercaces. Is it intuitive
> interface if absolute symlinks are accepted? I think it is as the file
> requested would have had the exactly same address if given in
> dhcpd.conf in the first place. One thing that could need some
> polishing is the error messages in nfs.c, which I will care for later
> (this evening). If the error messages states clearly "file not found"
> or, resp., "invalid filename", the user should be able to fix his
> config files. Just a pity that distinction between file and directory
> and so on is not so easy without non-trivial changes in nfs.c which I
> not really wanted to do. I think a message if type "This is nor a
> valid file nor a link to a file" would be enough for most users to
> find out where the problems originate. The same is my motivation for
> the display of "Loading syslink:<filename>" when following symlinks:
> This makes finding errors easier.
I like the Loading symlink: message that makes it much clearing what
is going on.
> Anybody disappointed because of the 16 symlinks link depth that I set
> arbitrarily? I had the case that in endless loop a->b->a after several
> dozens (I had no motivation to count them) of symlinks the system hung
> (stack overflow or so?) - so I decided to set an arbitrary limit.
Hmm. I wonder what would have triggered a stack overflow? As I
recall the kernel has a very similar limit for nested symlinks. For
the case of booting I have trouble seeing more than one symlink being
needed so 16 should be plenty.
Eric
|