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

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

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            =   [EMAIL PROTECTED]
Senior Systems Programmer           or  [EMAIL PROTECTED]
Rensselaer Polytechnic Institute    or  [EMAIL PROTECTED]

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to