|
From: <ebi...@ln...> - 2003-07-15 18:59:49
|
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 |
