Date: Sun, 17 Jun 2001 21:16:24 -0400 From: Garance A Drosihn <drosih@rpi.edu> To: Matt Dillon <dillon@earth.backplane.com>, "Andrey A. Chernov" <ache@nagual.pp.ru> Cc: Jordan Hubbard <jkh@osd.bsdi.com>, bde@zeta.org.au, imp@harmony.village.org, steveo@eircom.net, david@catwhisker.org, current@FreeBSD.ORG Subject: Re: symlink(2) [Was: Re: tcsh.cat] Message-ID: <p05100e0eb753048b371c@[128.113.24.47]> In-Reply-To: <200106172128.f5HLSe108208@earth.backplane.com> References: <200106170518.f5H5I6V44586@harmony.village.org> <Pine.BSF.4.21.0106172154520.582-100000@besplex.bde.org> <20010617113141A.jkh@osd.bsdi.com> <20010617231418.A60728@nagual.pp.ru> <200106172128.f5HLSe108208@earth.backplane.com>
next in thread | previous in thread | raw e-mail | index | archive | help
At 2:28 PM -0700 6/17/01, Matt Dillon wrote: >:On Sun, Jun 17, 2001 at 11:31:41 -0700, Jordan Hubbard wrote: >:> It seems your argument to disallow null symlinks got somehow taken >:> as an argument to disallow all "invalid" symlinks then. >: >: >:To say it more clear: now I even not against ""-symlinks making ability, >:such strings are valid per POSIX after all, as already noticed in this >:discussion. I am against _resolving_ them to illegal "" name (and to "." >:in pathnames) which cause all errors that Bruce describe. >: >:-- >:Andrey A. Chernov > > This is a reasonable distinction to make. If someone actually > tried to open() a ""'d symlink an argument can be made to return > a specific error rather then trying to resolve it. I'm not sure > it's worth it, though. I think that it's reasonable to just make it a specific error, and thus end this thread. No harm will come of making it a specific error on open, and it will address the problems mentioned earlier. When I say this, I assume that the only change to make is how any 'open' or 'stat' call will handle null symlinks. If I am reading Andrey correctly, there will be no change to the 'ln' command or the symlink() system routine. Assuming this is true, is there any downside to making open() and stat() return an error for a null symlink? I generally prefer returning an error at the earliest point it can be determined to be an error, and thus I think it IS worth it to make this an error at open() or stat() time. I see no benefit in letting those succeed only to have some strange error occur in later processing. I do not care if this is or is not a security error, I am talking about saving someone time when debugging a side-effect of having a null symlink. I think that's my 2 cents on this issue, although later on I may find I'll want these 2 cents back and will contribute a different 2 cents. -- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?p05100e0eb753048b371c>